The examples are kinda dated but the approach is pretty timeless.

Refactoring to Functional–Why Class?

This is a multi-part series on Refactoring to Functional Programming

Read Refactoring first than read Design Patterns(GoF).

Design Patterns is also very well known https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...

I also love Feathers and Working Effectively with Legacy Code, but that might be more of a niche taste ;)

I am a UX person, but often dabbled in Ruby on Rails. Currently for the the first time working on a more serious app and now reading the book refactoring ruby, is very illuminating, going through my code again and rereading makes me see many mistakes and possible improvements.

Besides that, I am currently reading Scala in Depth (Suereth) and re-reading Refactoring (Fowler).

[0] https://martinfowler.com/bliki/DesignStaminaHypothesis.html

Martin Fowler's book 'Refactoring' gives names a whole bunch of these. That might be where the op is coming from.

Then I'd move on to Domain Driven Design and probably Refactoring and Growing Object Oriented Software, Guided By Tests.

Those four will give a good start to what enterprise/OO people are expecting in design.

This can be seen for example in the intro chapter to Fowler's 2nd edition of Refactoring, where he pulverizes some code into submission.

[1] https://www.refactoringui.com/book

[0] https://refactoringui.com/previews/building-your-color-palet...

Feathers (the author) methodologically chose to copy / inspire some of his examples from code he's worked with as a mentor / developer (some of it from his time @ Thought Works w/ Beck, et al.)

The book is similar to Fowler's Refactoring in that it provides some core thought processes / ideology and then a long list of heuristics and techniques for revising/updating legacy code. (I find his definition of "legacy code" as any software without automated testing to be challenging and insightful, especially since it indicts most code written ever. ;)

If you get the chance, you could also consider reading "Clean Code", it doesn't have /as much/ "real world" source but is still excellent.

But from the writers:

    * Refactoring
    * Patterns of Enterprise Application Architecture
    * Smalltalk Best Practice Patterns
    * Agile Software Development, Principles, Patterns, and    Practices
    * Domain-Driven Design
    * Structure and Interpretation of Computer Programs
    * The Pragmatic Programmer
    * Design Patterns
    * Analysis Patterns
    * Implementation Patterns

Refactoring (Martin Fowler).

Speaking of the Matrix, eXistenZ (very strange), and the Thirteenth Floor (didn't watch it), and probably some others with a similar theme like that also came out that year.

"Refactoring" is not the tool for the job, although it's a nice sidearm.

What OP needs is the big gun, Feathers's "working effectively with legacy code": http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...

As the title hints, it was written specifically and expressly for the "I just got a huge amount of complete shit of a codebase shoved unto me, how do I survive". Just check the TOC of part 2 (the meat of the book): http://my.safaribooksonline.com/book/software-engineering-an...

> And of course, make sure your client acknowledges that it's a giant clusterf...

That's hugely important. No promises of delivery, and that the client understands it's not a cakewalk.

1. Identify a small and easily separable piece of code (what you woud call a component in a normal system.)

2. Write tests covering every (important?) edge-case of the piece of code you want to rewrite.

3. Mercilessly refactor until it's nice and squeeky clean.

4. Lather, rinse and repeat.

And of course, make sure your client acknowledges that it's a giant clusterf... and is on board with you pulling the system out of the stone age.

Also, if you want to make life a bit more interesting for yourself, get the PHP code's AST and programmatically rewrite existing code to shared conventions for kicks.

    Software Requirements - Karl Wiegers

    Programming TypeScript - Boris Cherny

    Associate Cloud Engineer Study - Dan Sullivan

    Design Patterns - Gang of Four

    Refactoring - Kent Beck, Martin Fowler

    Programming Pearls - Jon Bentley

    Patterns of Enterprise Application Architecture - Martin Fowler

    The Pragmatic Programmer - David Thomas, Andrew Hunt

    CSS: The Definitive Guide - Eric A. Meyer, Estelle Weyl

    Working Effectively with Legacy Code - Michael Feathers

    Head First Design Patterns - Eric Freeman, Bert Bates

    Code Complete - Steve McConnell

    Peopleware - Tim Lister, Tom DeMarco

    Clean Code - Robert C. Martin

    The Clean Coder - Robert C. Martin

    Clean Architecture - Robert C. Martin

    Don't Make Me Think - Steve Krug

    Functional Design Patterns for Express.js - Jonathan Lee Martin

    The Surrender Experiment - Michael A. Singer

    Principles - Ray Dalio

    The Power of Now - Eckhart Tolle

    The Effective Executive - Peter F. Drucker

    Think and Grow Rich - Napoleon Hill

    Extreme Ownership - Jocko Willink, Leif Babin

    Influence - Robert B. Cialdini

    The Startup Way - Eric Ries

    The Lean Startup - Eric Ries

    12 Rules for Life - Jordan B. Peterson

    Measure What Matters - John Doerr, Larry Page

    The Fish That Ate the Whale - Rich Cohen

    The E-Myth Revisited - Michael E. Gerber

    The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh

    Management - Peter F. Drucker

    Thinking in Systems - Donella H. Meadows

    Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne

Apprenticeship Patterns by Adewale Oshineye and Dave Hoover: A set of "design patterns" for your career as a software engineer. I read this relatively late on, when my career was in a bit of a rut, and I credit it for giving me the motivation and the tools to get out of that rut. I wish I'd found it earlier.

Other brilliant non-technical books: The Manager's Path by Camille Fournier, Radical Candor by Kim Scott, Mastering Communication At Work by Jon Wortmann and Ethan Becker, Mindset by Carol Dweck, Drive by Daniel Pink, The Power of Habit by Charles Duhigg.

Some brilliant books focussing a bit more on tech and code craft: Growing Object Oriented Software, Guided by Tests ("The GOOS Book") by Nat Pryce and Steve Freeman, Refactoring by Martin Fowler, Clean Code and Clean Architecture by Bob Martin.

Rewrite.

Write some code, make sure it works, and then look at places where it's ugly and figure out how to rewrite it so that it's better.

You won't write good code the first time, unless you're writing something that's trivial for you (too easy).

While the examples are too Java specific, the book Refactoring by Martin Fowler is a terrific introduction to the skill of improving code.

Being able to slice projects that way, in terms of functional behavior, is absolutely a skill that requires practice. You are already thinking about what your code needs to do: the practice is to get good at expressing that in terms the computer understand. Once you are in the habit, the tests make it easier to evolve the code rather than harder.

It is possible to be a good developer without that skill, but learning and practicing the skill will make you better.

Unfortunately I'm not qualified enough to judge those things myself, I just learned that I must doubt about anything, even if it seems to come from big names.

But here are a couple of Martin Fowler quotes (from his Refactoring book) I tend to follow:

“A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.”

“Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.”

https://www.goodreads.com/author/quotes/25215.Martin_Fowler

Fowler wanted to write the book using Smalltalk, but because the techniques he wanted to write about were fairly language agnostic, he did it in Java, as that was more popular. Unfortunately I think a lot of programmers missed the point, and now think refactoring is only something that can be done well in languages like Java (static typing) and with IDE support.

He's announced a second edition[0] in which he'll use JavaScript, to again prove the point that the techniques matter less than the language (other than sometimes techniques that work for class-based designs aren't as relevant as for function-based designs) and because JS is so popular. I'm not optimistic it will help anyone see the underlying point, but at the very least it might kill the idea that refactoring has to be hard in non-static-typed languages.

[0] https://martinfowler.com/articles/201803-refactoring-2nd-ed....

Really good software engineers write more than code. They know how to clearly outline ideas than can be handed to other developers.

I think the idea of an architecture as a social construct is very fitting. Software is hard when multiple people are working on it with differing backgrounds and experience. Having a rough outline (emphasis on rough here) of "what lives where" and "what is allowed to talk to what" is absolutely critical IMO. It's how your team can effectively reason about a system and add new features to it. It should also be a living thing in that it's something that is continually refined, discussed, and changed as the needs of the business change. Done right, its an organic process that really helps deliver more robust software that everyone involved has a high level understanding of.

Contrast that with an Architecture (capital A) done in Enterprise which delivers a static artifact that does not allow for any creativity and micromanages every aspect of it. It's split off into chunks and no one without an expert level of knowledge can easily understand it. That kind of design will almost certainly fall over the first time there needs to be a change to it. It's important to point out the difference because that is NOT what Fowler is recommending in his writings.

To put this in context: I keep it next to "Agile Software Development" (by the same Uncle Bob), "Working Effectively with Legacy Code" (by M. Feathers), and "Refactoring" (by M. Fowler).

HTH (no, I have no direct or indirect benefit from 'advertising' these books and their authors)

http://thecodelesscode.com/case/33

You might want to do some reading of books about how to promote institutional change from within. If you can read, and then get your manager to read, "Creating a Software Engineering Culture" by Karl Wiegers, that might help. Also, "Refactoring" by Martin Fowler is highly advised.

Regardless, maintaining good relationships with your coworkers, and specifically your manager is key. One key insight I have gathered over the years is that whenever possible, there are benefits to avoiding telling someone "this is a problem/bad/whatever and needs to be fixed" if it is instead possible to say "That's great, and it would be even better if..." The criticism in the first form invokes a immediate defensive reaction once someone hears "this is a problem" which may cause them to not hear whatever you say next, and can create a teacher vs. student dynamic (see Pavlov's work on negative conditioning) in which they may actively start to resist your suggestions, while the second form is more likely to cause them to feel good at having been praised and want to seek further approval (positive conditioning, which tends to be much more effective and produce more long-lasting behavior changes in most circumstances). Some research on self-serving bias suggests that people are much more likely to believe what you are telling them if you can phrase it in a way such that it sounds like praise.

Good luck!

* Design Patterns: Elements of Reusable Object-Oriented Software

* Refactoring: Improving the Design of Existing Code

* Clean Code: A Handbook of Agile Software Craftsmanship

* Code Complete: A Practical Handbook of Software Construction

And some others:

* Working Effectively with Legacy Code

* Domain-Driven Design: Tackling Complexity in the Heart of Software

When I first read Refactoring, IntelliJ wasn't released yet and refactorings still needed to be done by hand. Automated refactorings are so incredibly useful when it comes to improving code quality over time that I don't know what it was we did without them.

Don't take this as advice against learning what you want to learn, but I'd caution against the idea that "object-oriented programming" and "good programming" are the same thing (or even that they are correlated). OO in its various incarnations comes with a tremendous amount of baggage. It took me years to figure out I didn't need it, and that insight made me a much better programmer.

Of books that are more on the craft of programming, "Refactoring" (Also Fowler) is good. And I enjoyed "Practical Common Lisp" by Peter Seibel too.

In general, I suspect that the value of a book has more to do with where the reader is, than where the book is.

Edit:
Additionally, some which have been mentioned or not:

- a couple of biographies of Lincoln (one is free on gutenberg.org, the other more recent by Doris Kearns Goodwin), and one of Washington whose name I forget now, but there are good ones out there.

- the 7 Habits book (Covey), and How to Win Friends and Influence People by Carnegie.

- Refactoring ..., by Martin Fowler.

- some thick Scheme programming book from college (sorry, it's downstairs). And "The Little Schemer", also about Scheme (one of the authors, Friedman, was also our instructor).

- Since Cumorah, by Hugh Nibley (maybe dated now, but there is a lot of related work). Really got me interested in related topics.

When that awful Design Patterns book was off the hype train but the new devs had heard about it and asked if they should read it, I would tell them No, read Refactoring twice instead, because it tells you why and when to use this stuff, which is much more valuable. Like feature work, if you know why you are doing something you can often reason out the gaps in the “what” on your own.

We sort of take a bunch of XP processes as a given and forget that this was Agile for most people at the time of the manifesto. Scrum pretends it’s separate but is essentially useless without half of XP.

He's a self-proclaimed "expert" and a "leader". Yes, he's basically saying right there that he is an authority on writing code.

That being said, I've read some of his Refactoring book awhile ago, and it's mostly good advice from what I remember.

When I was in college, I read "Refactoring to Patterns" which pretty much sums up Refactoring in a short chapter. The ideas aren't really that complicated, but seeing some practical examples is pretty useful.

[1] https://www.martinfowler.com/books/r2p.html

If we're talking about technical books, Refactoring is easily the most beneficial read I can remember having. I was pleased to see it (barely) trump Design Patterns... a book that I think (through no real fault of it's own) has spoiled more developer-years than it's benefitted.

Martin Kleppmann's Designing Data-Intensive Applications. Based on the frequent praise it receives here, haven't gotten far yet. I have some project ideas (for personal and professional projects) that could benefit from reading through it.

Martin Fowler's 2018 update to Refactoring. I read the original one a long time ago. In context, we have a work lunch & learn series and I'm interested in doing some presentations on the topic of refactoring (why, how, and when in particular) so it seemed appropriate to refresh my memory on some specific terminology from the book as well as to see if it's an appropriate book to recommend to colleagues. My recollection of the first edition is that I'd recommend it to colleagues, but it's been so long I'd rather read it once more before actually recommending it.

I reread Robert C. Martin's Clean Code based on some recent discussion here where it was rather strongly dismissed by a fair number of people. I didn't recall it being bad, my reread confirmed it is not, in fact, bad. Java-heavy, which is now an unpopular style of OOP, but otherwise a very good book. I'd still recommend it to junior colleagues paired with some caveats about avoiding seeing the world in black & white. There is no singular Way of Programming, but learn various ways and find what works for you and your team.

There are some more, but it's almost 5am and I haven't been able to sleep so I don't recall everything that's in the book stack or ebook queue. These are the ones I'm most interested in at present.

I'm only a very new programmer, but I'm reading Martin Fowler's Refactoring and, even from my limited experience I'm finding that one of the differences between software and other products is that software must be maintainable. So the end user isn't the only end user. Software has to be read and worked on by other programmers in future, and most of the craft involved is not in making a program simply work as it's supposed to, but making the code easy to read, easy to maintain, and easy to modify.

So the aesthetic quality of the code and the craftsmanship involved is very important, for pragmatic and eventually end-user-facing reasons.

But hey, what do I know? I haven't gone to programmer's school or gotten a programmer's license or anything.

Patterns of Enterprise Application Architecture by Martin Fowler.

Domain Driven Design by Eric Evans.

Growing Object-Oriented Software, guided by tests by Steve Freeman and Nat Pryce.

Once the technical debt is so deep that bankruptcy seems like a good option, digging out is also not a great option. It's certainly possible now if it wasn't then; people like Michael Feathers have done great work charting paths out of an accumulation of garbage code. But at the time of JWZ's resignation letter, Martin Fowler's book Refactoring had been out for all of 3 months.

In particular, Netscape was faced with a choice: they could either do a total rewrite quickly, or take much longer to do a slow rewrite while still pushing forward, but at a much reduced development speed. That's fine if you're some large enterprise in a stable field with a solid revenue stream. But a startup competing in the then-fast-evolving world of the Internet? Competing against the monopolistic giant of Microsoft, who was desperate to dominate the space?

There's little reason to think a slow cleanup would have been any better than a fast rewrite for Netscape. Especially if their solution involved open-sourcing things, which a) requires a non-awful code base, and b) reduces the pace of refactoring and cleanup. So I think it's fair to say that either way Netscape was killed by technical debt.

He takes you through a piece of code and refactors it all into smaller and more usable parts explaining what he's doing along the way. He does this with two difference pieces of code, if I recall correctly, then the third part is an index of all possible refactors.

I read it cover to cover in less than a week and has totally changed the way I program.

It's also not too different to what old books like Fowler's refactoring or the Working With Legacy Code book say, or what modern books like Philosophy of Software Design say.

A couple books that are worthwhile: "Refactoring" and "Rapid Development". That will teach you a lot of basic skills in terms of development process and how to improve the design of real systems (warts and all). Also, take a look at the Architecture of Open Source Systems, it'll acquaint you with how applications fit together.

Also, take on some projects. Pick something interesting and work on it. Pick some small stuff then move up from there. I'd suggest in your case eventually building a compiler. If you're interested in AI, build some simple games and work on building AI for them. There is nothing more important than actually writing code.

> We may have diluted the meaning of refactor

And I will quote the summary for Refactoring by Martin Fowler:

> Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing"...

If words don't mean anything it's really hard to have conversations and it's insanity to try to create strategy around them.

This post almost seems to be turning out to be an AskHN, with everyone chiming in on their 'career-changing' programming books.

I think that it is fair to say that my book is partially also about Node.js, but not primarily. I wouldn't say though it is about JS. In fact, many of the code examples would look similar in other languages. Furthermore, the use of Node.js helps to provide concise code examples and executable code without much ceremony.

When reading "Implementing Domain-Driven Design" by Vaughn Vernon, all the code examples are in Java. The book "Enterprise Integration Patterns" has a lot of code examples and all of them are also in Java. The most recent edition of "Refactoring" by Martin Fowler uses JavaScript. Still, I wouldn't say that these books are about a particular programming language.

I think "catalogers" as I'm thinking of them are by nature not quite pioneers, since the fundamental move of cataloging is to describe and categorize what already exists, but might often be settlers, in the sense that a good career move for a cataloger is to be the first to apply a new process to gain insight into new distinctions or categories. In that sense I would see GoF themselves acting as "settlers" in their Design Patterns book, which I tend to view as a catalog project.

However books like "Refactoring", and "Working effectively With Legacy Code" also turn into partial cataloging projects, but those might overlap more with "town planner" in that they're really leveraging some mature technologies and looking for system-level economic savings of readability/changeability/maintainability.

So I guess I'd continue to argue that it's a "mindset" as much as "a type of person"; "Working Effectively With Legacy Code" isn't _only_ a catalog, but there's parts of it that come from a catalog mindset.

Regardless, I hadn't seen the above mapping you linked and I appreciate it!

Write code first. Write code until your programs collapse under their own weight. Then go out and read what the masters have written. You'll understand it much better when you have personally faced the problems that they were facing.

Is there sample code illustrating the pattern language?

> let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

That said, if you know how to refactor safely even without tests, you can make improvements. Since the questioner is working in JavaScript, Martin Fowler came out with a second edition of Refactoring with JS code that might be useful.

I've never read the first edition (in Java) but Michael Feathers' Working Effectively With Legacy Code is a frequent recommendation of mine. Its main goal is to get your mess under test, ideally tests that help you understand the system as well as improve its quality. It's organized as a set of questions one finds oneself asking in these kinds of code bases and some ways to resolve them: https://www.oreilly.com/library/view/working-effectively-wit...

But now that you mention it, I haven't actually read Refactoring :| The knowledge actually required for programming is tiny compared to what's available; people's exposure is all over the map.

Also quite like Fowler’s observation in Refactoring that (to paraphrase) abstractions are earned, not enforced.

Without looking at the book, a few things from Feathers I think about often:

- The concept of "sensing" is useful when thinking about test design. I alternate between state-based TDD vs. a more behaviorist/mockist style depending on whether the code's job is fundamentally about managing state, or routing requests to other components (a surprisingly useful distinction)

- Converting methods to "virtual" can be pretty useful when it's too hard to introduce an interface, but you want to mock/stub out a component

- "Sprouting" is a nice way to think about how a class can "Grow" out of existing code, same for methods and parameter clumps (from Fowler)

- It's also a darned humorous and funny book. "The case of the irritating parameter", "Help, this code just calls a bunch of other code", "This class is impossible to get under test", etc. I love the writing style and how he stops just short of hyperbole while still making me grin.

- Programming Voice Interfaces = no reviews

- Mobile App Development with Ionic = 3.5 stars (3 reviews)

- JSON at Work = no reviews

- Refactoring JavaScript = 5 stars (2 reviews)

- CSS Refactoring = 4 stars (4 reviews)

- Interactive Data Visualization for the Web = 5 stars (16 reviews)

- Learning React Native = 5 stars (2 reviews)

- Learning HTTP/2 = 4.5 stars (7 reviews)

- SVG Animations = 4.5 stars (8 reviews)

- Working with Static Sites = no reviews

- React Native Cookbook = no reviews

- CSS: The Definitive Guide = 5 stars (13 reviews)

- Using SVG with CSS3 and HTML5 = 5 stars (1 review)

- Learning React = 4 stars (22 reviews)

- High Performance Images = 5 stars (1 review)

The sample size of reviews for most of the books is a little limited, but I'm planning on picking up the bundle at the $15 level anyway -- CSS: The Definitive Guide is well-reviewed (and expensive by itself).

Refactoring is when you rework a specific section of code, usually that you're about to work on, or just worked on, to be cleaner. It's a long-term approach, and it's how large applications stay maintainable over the long term. For your specific example, you'd leave your app alone. You wouldn't rewrite it, or touch it, until you find a bug, or need to add a new feature, and then you'd rework anything you need to to add the feature cleanly.

On a related note, Refactoring by Martin Fowler is a great book, and I'd recommend everybody pick up a copy. It's a beautiful hardcover and looks great on a shelf, too.

http://www.amazon.com/Refactoring-Improving-Design-Existing-...

I recently picked up a copy of The Mythical Man-Month, from 1975. There's hardly a line in it that doesn't still apply today.

I've been 100% python for the last few years, after a career mostly in Java and I definitely miss the sweeping refactoring abilities and hard-breaks during those kinds of refactorings. It does lend courage for sure. I'm just SO MUCH MORE productive in python for most of what I do that I'm not willing to throw out the baby with the bathwater yet. Instead I've been trying to focus on leveling up test coverage, and experimenting with Rope for refactorings ( http://rope.sourceforge.net/ ). I'm also slowly learning patterns for coding to make refactorings easier moving forward.. choosing code and data structures that are more easily affect-able later, or even things as simple as naming things for grep-ability.

The second thing that has really influenced my coding style for the better (making it clearer and easier to understand) is writing a medium-sized program using a strictly functional language like Erlang. This will force you to use global state less, to write functions in such a manner that the function itself includes all the information required to understand it, simply because global state cannot be used and everything on which the function operates must be passed into it explicitly via its parameters.

[1] Clean Code (Robert Martin)
http://amzn.to/2uewcpB

[2] Refactoring (Martin Fowler)
http://amzn.to/2vnD7vx

You might find that most of the Design Patterns and even some of the Refactoring book are focused on working around limitations in Java/C++-style languages.

>Although, I should probably get around to reading Refactoring, and Design Patterns

I'd been programming for 20 years before reading either.

Both were...entirely unsurprising. Design Patterns at least defined a useful vocabulary for talking about different patterns, so I found it useful in that respect, and at least some of the patterns are useful outside of a Java/C++ language. Refactoring had some good wisdom on OO design, but it was pretty much all stuff I'd picked up elsewhere or come up with on my own.

Wouldn't hurt to read through both at least once to see if there are any surprises for you. Might be safe to just check them out of the library, though. I kept Design Patterns around but gave away my Refactoring copy.

I use intellij which can offer inline parameter name hints, I think that's a good middle ground but it doesn't make things more readable outside of that editor.

Saying that whoever recommends Code Complete made some wrong life choices is a bit rude and uncalled for. Books are just tools, the benefits they bring depend on whether the reader goes through them in a smart way or not.

Then again, but this is a matter of taste, I would suggest The Pragmatic Programmer as a first read. It's shorter, well-written and with laser-like focus on the topic at hand.

Lastly, since designing and writing software is as much of an art as it is science, what's really important is to avoid reading passively and blindly applying anything the knowledge one finds in a book, and instead strive to understand why, and going against the grain and see why certain practices are called "best".

I think the article has the premise that once you remove duplication you have committed to using that abstraction and need to shoehorn all future changes into that function. That’s a ridiculous notion. You can simply refactor it again if the abstraction no longer makes sense.

Thinking about the above further I notice the things I've learned over the years also require the ability to link problem to cause, or in my case it came in reverse, cause linked to problem.

I ran into problems for years, learned how to fix them, and then during code reviews (even in self review), discovered the cause behind these problems.

Sometimes these were causes that would only become problems at a later date because of knock on effects.

I don't know how you teach that. Possibly antipatterns / code smells which usually hint at underlying problems that may be elsewhere / at a different level.

Refactoring by Fowler and TDD by Beck cover a lot of these in good detail.

But personally, I'd like to ask what business goal are we looking to solve? Because regardless of how murky a codebase can be, if that codebase keeps hitting a business goal, then we really can't drive a change in practices.

So, we first present business goals. Here's a few examples:

If the business goal is to give better estimates for fulfilling custom features faster, then testing would be the first in the list. Not even the release process. Tests lessens cognitive load for developers when they're asked "how long can we make this feature?". They'll have an idea that it'll probably break a bunch of services, etc. a.) If you're in leadership, ask for tests when people make a PR. b.) If you're not in leadership, look for the smallest part of the monolith. Write 1 integration test, add a CI integration, put it in a PR. Co-workers would probably like that.

If the business goal is to give better SLA's (turn around time for addressing breaking bugs, scaling better), then the release process would come first.

Regarding technical debt: One way to address technical debt is to slowly address it by folding in the effort of cleaning and refactoring inside a feature request. ex: making a new form about 2FA takes 3 days, but you can say 7 and explain that we'll setup a CI test build, then hit and address some debt regarding User Authentication along the way.

It'll introduce as a "Clean As You Go" culture in the legacy engineering team, which will pay off in the long-run instead of having a huge amount of time just dedicated to addressing technical debt.

The danger of separating "address technical debt" as a separate effort is it sometimes results into some unnecessary abstractions and over-refactoring: i.e. trying to make certain things too generic, bordering on building a framework.

But then again, if the business goal was to make a framework for a business goal (maybe something the bizdev can sell), then it can definitely be made as a separate effort. Otherwise, it'll be seen in the bizdev as someone just "playing" around with tech.

For years I felt like a terrible tester on a team of even worse testers. I still catch myself using antipattetms I tell other people not to use.

Honestly the two biggest things I know are try to write pure functions, and separate deciding from doing (these are not mutally exclusive), something Meyer also talked about. That will open up a lot of your code to simple tests with few mocks.

Book advice is going to sound like a non sequitur. I find bad habits in many of the testing books I’ve read, like the author hasn’t root caused common problems that pop up on real teams. You can’t blame human frailty for your testing problems. Testing is a monument to human fallability. Own it.

You can fix a lot of classes of problems with Refactoring by Fowler. There’s a second edition due out in a few months. I hope it maintaina the value judgements and thought processes if the original.

With structured code, if you put a statement after a block it will be executed (notwithstanding exceptions, but that is a slightly different matter...), no matter what is changed. But if you have returns, breaks, etc. that structural condition is lost.

If you have a function with a statement, or block, at the very end, to clear something up or something, but then someone puts an early return in, the clear-up will be missed. There is a certain error-proneness there.

The best use of the early-return pattern ('replace nested conditional with guard clauses' in the Refactoring book) is where that is the only thing going on in the function. So you are effectively reading/understanding the whole thing as an 'early-return function'.

(And software is very different from natural languages. When you look at software what you see is not language, but a machine. And it has a particular hierarchical structure.)

Not entirely, anyway. You can't turn the whole app into a good one in any reasonable time, but when you fix a bug, take time to apply the boy scout rule ( http://www.informit.com/articles/article.aspx?p=1235624&... ) Don't put that down as a separate task that your management can approve or deny, it's part of doing the job of coding properly. That way, at least the buggy parts of the app get better.

You should not be focused only on your career when making coding and tech decisions, but look at it this way: in a year's time, you're in an interview for a job you really want. What are you going to say "I can read and maintain shitty code" or "I can make shitty code better"?

Also consider: documenting your app's architecture (or lack of it) and conventions (or lack of them).

Also consider: reading up on architecture, testing, refactoring and code quality. If nothing else, these will help you get your next, better job. Off the top of my head, try "Domain Driven Design" by Eric Evans, "Growing object-oriented software guided by tests", "Refactoring" By Martin Fowler, and on the last topic "Clean code" by Robert Martin and "Code Complete" by Steve McConnell

Big ball of mud apps (http://www.laputan.org/mud/ ) may be common, but it doesn't have to be that way - you can learn some pitfalls to avoid

But I don't think the book, in itself, can cited as evidence that he's built large, real-world systems.

There's a big step between "no experience" and "major experience with large scale, distributed systems".

When I had six months of programming experience, I could do a fine rendition of the standard OO doctrines. With far more experience now, I can mostly describe how they fail to operate in the real world.

I can think of two different major projects I've done in the past five years in which I started again from scratch, after major revelations made it clear to me that it was the right thing to do. In one I settled on the third object model, and the other I know I did at least two. These were quick iterations though: I settled on the third and final object model within a month of starting, and the project completed in seven months, so it's not like I was throwing out that much work.

Avoid premature optimization with all your might.

Fowler's book Refactoring might be helpful with ideas of how to morph data models.

A couple of quotations from More Programming Pearls by Jon Bentley:

"Plan to throw one away, you will anyhow." [Fred Brooks's law of prototypes]
"It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror." [Thompson's rule for first-time telescope makers]

Another kind of over-engineering is speculative optimization (often called "Premature Optimization", but I like to emphasize the speculative nature of it, because that's the heart of the issue). Am I working to make the system faster in response to actual evidence of a performance problem, or am I just guessing about performance?

Over-engineering isn't always bad. It's all about predicting the future and weighing risks, with everything that entails. It's hard, but it's a fundamental part of design, and of life.

Whenever I'm unsure about whether a particular speculative generality or optimization is justified, I try to step back and find implicit assumptions. I try to turn "This might help some day" into "I'll need this if XYZ happens". If I can't do that, it's a bad sign.

And I agree with the original author's point: making mistakes in places where you can afford to fail, or where you can afford to recover, is a great way to learn.

My alma-mater (UBC.ca), the CS Dept touches a few subjects:

- Design Patterns (still using GoF, which is probably not the right fit for 3rd year students)

- Refactoring (we do refer to Martin Fowler's book albeit we don't dig that deep)

- Barbara Liskov book (touches a few thing regarding type-systems and its relation with OOP, IN-OUT contract/verification, a bit more academic/formal but most of us saw her work in C# contracts, the L in SOLID principles, some of the OOP best practices probably).

    - C Programming Language (2nd Edition)
    - Refactoring: Improving the Design of Existing Code
    - The Mythical Man-Month
    - Programming Pearls

If you feel you've almost gotten OO, but not quite, then Refactoring is a great book. That one lit up the "ah ha" lightbulb for me.

The patterns are loosely what to do, but that's not the thing that lasts across the years and languages. Refactoring is why and how.

- Ready Player One

- Pattern Recognition

- Burning Chrome

- Do Androids Dream of Electric Sheep?

- Hyperion

- A Fire Upon The Deep

Technical (backend development + security)

- HTTP: The Definitive Guide

- RESTful Web Services

- Designing Data Intensive Applications

- Web Scalability for Startup Engineers

- The Art of Software Security Assessment

- The Web Application Hacker's Handbook

- A Philosophy of Software Design

- Clean Architecture

- The Go Programming Language

- Refactoring (new 2nd edition)

- Algorithm Design Manual

- Cracking The Coding Interview

I'll definitely be able to get through all the sci-fi novels, but not the technical stuff. At minimum I need to go through the technical interview prep books, refactoring, and designing scalable applications.

The books on the second list which I have read (at least partially) are books I have had reason to go back to at some point in my career, and any of them which I no longer have, I will likely purchase again.

More modern languages like Ruby will allow even cleaner ways of doing things than described in Refactoring (Java), but you can get a good sense for smells common to all languages.

Some other thoughts:

What science are you studying? There's often scope to do something computational for your thesis/project/dissertation - modelling some physical or biological process.

Other ideas:
Try and get an internship at a software company. Often a science degree is sufficient and you'll be able to learn about working in teams, using source control, and observe the kinds of things you like and dislike in a workplace.

You could also do a CS conversion course once you've finished this degree.

There are big problems with software development - complexity and requirement of the special state of the mind. This is why there are still no programming factories. There are already data-indexing and query processing factories, but you still should think and write.

All those methods, form Booch's RUP, Beck's XP, Fowler's Refactoring are an attempts to adapt scientific methods, psychological and human behavior models, and even religious concepts to the process of the writing software.

The point is that these common ideas can be also adapted to a business processes.

For example, RUP is about planning and circles of iterations - scientific approach. XP is about reuse human behavior - little steps, being sure you hadn't broke anything, look (run tests) at your beloved code 10 times a day. Refactoring is about continuous improvements, little changes, that makes your code easier to understand, which means easier to modify and support. This is, probably, from dictionary and guide-books writing. You're writing the code is for humans, not for compilers.

Of course, not one of these methods fits all, but you can make a mix by yourself. Some from there, some from there. It is like cooking. All sources and ingredients available - just try, learn on failures and try again.

"Refactoring" does not mean "previous programmer was an idiot". Often, the understanding of the problem and the way the code is used change over time. Refactoring is a way of bringing the out-of-control weeds back into healthy symbiosis with the larger garden of code.

I stopped telling clients a long time ago that I'm "refactoring" and instead I just add some extra time to all tasks to account for refactoring on legacy code.

#Recommend on HN:

--Infinite Jest - DFW

--A Supposedly Fun Thing I'll Never Do Again - DFW

--The Web Application Hackers Handbook - Marcus Pinto

#Recommended Elsewhere:

--On Intelligence - Jeff Hawkins

--Refactoring - Martin Fowler

--The Brothers Karamazov - Fyodor Dostoyevsky (re-reading/skimming)