Hacker News Reader

Comment by khazhoux | Hacker News Reader

I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this:

* Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress.

* Team B deliberates and deliberates. They try to avoid taking shortcuts. But in the end, even their code doesn't have the strongest tests, doesn't generalize for all the known use cases, etc. Team B never gets users or gains momentum, and their code+architecture was probably no better than Team A -- they just took 3x the time to get there.

View on HN

I had a lot of trouble trying to explain this to juniors.

The most important things is to have code that is easy to refactor when you know what you're doing (i.e. everything is working properly). Juniors I worked with had a nasty definition of a pretty code being split into a hundred files, each no longer than a screen, and each function no longer than 5 lines. The onboarding of new devs to such code was way worse than into a code that would be 10k lines in one file, but with a flat structure and less interdependency.

"Flat is better than nested" - The Zen of Python

I had an "everything should be broken into a hierarchy!" stage back when I was learning to code, and boy was I off track. In my defense, at the time (and this dates me) OOP was all the rage.

I find OOP spaghetti can be incredibly difficult to navigate, example: Class hierarchies 4 or 5 layers deep, some subclasses overriding the parent, others not. It can be it very difficult to follow what's actually going on.

Procedural spaghetti is more manageable, though I once had to update a C app with a 3000 line case statement. Pure madness.

I remember working on a project with endless exception class hierarchies - that was a monumental pain when trying to diagnose what led to an exception.

In a subsequent project we banned subclassing of exceptions.

Inheritance hell would be more lasagna code.

Golang does a good job of addressing this one particular problem.

This depends a lot on the development environment. In Smalltalk years ago, we were encouraged to limit each method to few lines at the most. This makes sense within Smalltalk and the code browsing inherent in the system.

It makes debugging in Java or C# an exercise in face shredding frustration. Where each class is in a file, it's better to structure the class consistently with other classes in the project, and things like naming conventions become a lot more important.

You could argue that the C/C++/Java/C# languages are fundamentally broken because they don't encourage the succinct, small class methods that Smalltalk did, but you could also argue that those small methods don't necessarily work very well in a different class of languages from Smalltalk and neither approach is really more productive than the other, with the caveat that Smalltalk is largely dead and irrelevent to modern programmers other than a curio.

> The most important things is to have code that is easy to refactor

Very true.

I'll just add that another most important thing is to actually take time to refactor, even when things are busy.

I spend maybe 1/3 of my time refactoring, and that feels good.

I like to refactor once I have passing tests and before committing.

Once you know it works take a minute to clean up and make the changes fit your preferred style, extract repeated code into shared methods, comment the tricky bits, etc.

This Is The Way

> The most important things is to have code that is easy to refactor

This whole post is about how refactoring doesn't matter because your project's development lifetime isn't long and wide enough for maintentance to matter.

Less interdepency is absolutely the key to everything.

But... isn't the easiest way to show that there is little interdepency to put them in separate files that don't import from each other?

People misjudge where to draw the lines. You will have an orchestration API call that does five things and each of those five things, not used anywhere else, will get its own class, interface, factory, and configuration, so to read thru the five things you have to open like twenty files. And to notice that despite all this engineering they have static credentials in the code itself, you have to be alert across so many lines of code. The whole thing can be one longer file that reads coherently and in fact lessens the cross class importing.

Be Team C.

Team C works like team A. However every time a feature ships, someone who knows that feature well immediately refactors the relevant code to remove the prototype scaffolding. When code becomes static, an expert adds good quality comments. When a bug is found, it is recreated in a regression test prior to being fixed for good.

The sad reality of tech companies is that there is little incentive or bonuses for improving the situation. You won't get a bonus for cleaning up the code or for rewriting rotten code.

Hack at the code for 4 years, collect your options and leave the mess to someone else.

To be honest, a hacky codebase written fast is not the worst codebase to deal with. The worst type is when someone had the time to overarchitect and overengineer things.

Following references across 200 different files, tracing calls through hundreds of microservices. Graphql servers with complex resolver logic.

> The worst type is when someone had the time to overarchitect and overengineer things.

I concur. Refactoring should be as much about removing unneeded abstraction and features as it is about adding same.

> there is little incentive or bonuses for improving the situation.

Yeah, I just can't seem to believe this in my soul. I just want to fix ugly code and can't stop myself. I get huge satisfaction from speeding up, tidying up or fixing up bad code.

It doesn't help when management wants to minimize time spent on such tidy-up, especially when it's hurting our productivity to maintain it without fixing it.

Just do it. Don’t ask for permission. You will end up more productive not less.

This - I've been doing this for years now and simpler code (both simpler logic and the removal of unused code) makes working on legacy codebases feel completely different.

Yep exactly my experience. That combined with solid tests => I spend almost 100% of my time adding new features instead of staring at code and fixing bugs.

I try to sneak in refactoring with other tasks.

I find the best method is:

1. Figure out what needs doing and what code you need to use

2. Refactor the code you're using until the new code or change is easy

3. Make the change

4. Tidy and document.

Repeat

I often also document during step 1, while I am trying to understand code and realise that comments are missing.

4 years is a long time to suffer through inscrutable code.

I don’t think this dichotomy is helpful. I’m presently working at a startup that’s trying to dig itself out of a hole created by the first CTO, who in doing things “quickly” created an MVP so buggy, inefficient, crash-prone, and unmaintainable that we can’t retain customers or engineers. As always, there’s a balance to be struck, and ways to operate quickly that don’t sacrifice quality too much.

I'm kind of surprised that you can't find engineers interested in creating a new implementation of an existing application that is actually used by people. I think that might be my dream role.

At the risk of crushing your dream role, re-implementations can be long slogs. I'm in the middle of one right now. The Product owners don't know what the thing does. The engineers who originally wrote it are gone, and their replacements are relatively new to the codebase. The bright side is customers are hugely interested in our progress to date and we've received positive feedback. The business wishes we could move faster.

> The Product owners don't know what the thing does.

This is the dumbest part. You’d think that someone documented something when they originally built it, but nooo. Don’t even know the requirements, just that it has to be the same as the previous one.

Business doesn’t want us to stop the bus to change the tires - or spend so much time changing tires that the bus never reaches the destination.

Makes me think of Lightning McQueen losing the first race in Cars because he refuses to pit to change his tires, then blows them out on the last lap.

That type of role typically requires senior engineers at a junior salary

If your dream job could be in Charleston SC lets chat :)

I think something that is lost in this conversation is that "quickly" maps to wildly different results in code quality depending on the programmer.

It sounds like your CTO did not just operate quickly, but also sloppy and chaotic. From what I am gathering from this thread, the best practice is to move quickly AND organized such that refactoring is reasonable.

There's a YouTube video about beginner musicians vs intermediate vs advanced.

The beginner uses simple chords

The intermediate uses advanced chords, crazy fills and runs and riffs.

The advanced uses simple chords

"First there is a mountain, then there is no mountain, then there is."

That's not far from a similar saying in software: expert developers write code that looks like a beginner's, but simpler and with fewer bugs.

Beginner devs write code that is over-simplified, and needs hack on top of hack to do anything useful.

Intermediate devs write code that is over-engineered in places where it could be simple, while still needing a lot of extensive refactoring in the parts that deal with irreducible complexity.

Expert devs think deeply about the problem at hand, understand where the complexity is, and create a solution that is as simple as possible, but no simpler. After the fact, beginner and intermediate devs tend to think of this code as something trivial, that anyone could do.

This is why it may sometimes be tactically useful for the expert dev to sometimes take on projects that some beginner or intermediate team has been struggling with for some extended period of time, analyze it properly, and show how elegant the difficult parts can be solved.

Care is needed, though, as it can affect the morale of the other devs and even cause hostility. If the expert dev has a secure position in the organization and want to keep those other devs around, keeping a low profile as well as letting those devs take as much as possible of the credit is adviced.

"It took me a lifetime to paint like a child." -- Picasso

I kinda agree on this, but not for the implicit reason you're probably thinking of.

Just starting and doing it is just unreasonably effective because very few projects actually need novel solutions - most are just fine with off-the-shelf hacked together solutions.

Thinkers are required if the software is actually groundbreaking new work. Almost everyone's work on this forum probably isn't that however (mine included), which is why I agree with your sentiment

Plus.. When someone from Team B initiate the code, with hundreds of files & massive boilerplate, can't continue the work for a reason (e.g: sick / resign), this new dev who take the position will require super long time just to understand the code. Some of them will eventually writing their own, instead of following existing code standards, leading to have multiple standards at 1 project and resulting hell if it runs into trouble..

Also when someone from Team A initiate the code and Team B takes over, there were few times that Team B feels like the code is damn no good and just massively refactor it with what they think is good (re: the boilerplate) without others' concern. Then when Team B leaves, it goes to 1st paragraph..

I think as a team we need to consider the learning curve of our own code cz we don't code for ourselves.. And it's good to know the tolerance & acceptance to 'structure' of the code from other people..

Something this reminds me of that I've been doing lately when stuck on a particular problem is just coding something. Even if it's the most shittiest, inefficient and naïve solution. More often than not I either discover a more proper solution along the way or just realize my shitty solution actually wasn't all that bad to begin with.

Start with the simplest idea that might work.

https://news.ycombinator.com/item?id=19956614

Tests, ha

Reply on news.ycombinator.com