6 ms·

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,

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.

kolinko 5y ago
+1 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.
- BurningFrog 5y ago
  > 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.
  - jimbokun 5y ago
    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.
    - BurningFrog 5y ago
      This Is The Way
- gary_0 5y ago
  "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.
  - icedchai 5y ago
    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.
    - arealaccount 5y ago
      Inheritance hell would be more lasagna code. Golang does a good job of addressing this one particular problem.
    - jamesfinlayson 5y ago
      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.
- Scarblac 5y ago
  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?
  - lanstin 5y ago
    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.
- lupire 5y ago
  > 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.
- smackeyacky 5y ago
  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.
411111111111111 5y ago
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
wk_end 5y ago
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.
- notreallyserio 5y ago
  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.
  - 88913527 5y ago
    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.
    - Aeolun 5y ago
      > 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.
  - wk_end 5y ago
    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.
    - jimbokun 5y ago
gridspy 5y ago
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.
- jokethrowaway 5y ago
  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.
  - gridspy 5y ago
    > 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.
    - wsc981 5y ago
      I try to sneak in refactoring with other tasks.
      - gridspy 5y ago
        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.
kbrannigan 5y ago
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
- userbinator 5y ago
  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.
  - trashtester 5y ago
    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.
- jbmny 5y ago
  "First there is a mountain, then there is no mountain, then there is."
- khazhoux 5y ago
  "It took me a lifetime to paint like a child." -- Picasso
farmin 5y ago
Tests, ha
kcb 5y ago
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.
- baggy_trough 5y ago
  Start with the simplest idea that might work.
Mawr 5y ago
https://news.ycombinator.com/item?id=19956614 https://news.ycombinator.com/item?id=19956614
jordanmaulana 5y ago
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..

kolinko 5y ago

+1 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.

BurningFrog 5y ago
> 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.
- jimbokun 5y ago
  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.
  - BurningFrog 5y ago
    This Is The Way
gary_0 5y ago
"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.
- icedchai 5y ago
  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.
  - arealaccount 5y ago
    Inheritance hell would be more lasagna code. Golang does a good job of addressing this one particular problem.
  - jamesfinlayson 5y ago
    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.
Scarblac 5y ago
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?
- lanstin 5y ago
  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.
lupire 5y ago
> 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.
smackeyacky 5y ago
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.

411111111111111 5y ago

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

wk_end 5y ago

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.

notreallyserio 5y ago
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.
- 88913527 5y ago
  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.
  - Aeolun 5y ago
    > 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.
- wk_end 5y ago
  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.
  - jimbokun 5y ago

gridspy 5y ago

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.

jokethrowaway 5y ago
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.
- gridspy 5y ago
  > 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.
  - wsc981 5y ago
    I try to sneak in refactoring with other tasks.
    - gridspy 5y ago
      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.

kbrannigan 5y ago

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

userbinator 5y ago
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.
- trashtester 5y ago
  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.
jbmny 5y ago
"First there is a mountain, then there is no mountain, then there is."
khazhoux 5y ago
"It took me a lifetime to paint like a child." -- Picasso

farmin 5y ago

Tests, ha

kcb 5y ago

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.

baggy_trough 5y ago
Start with the simplest idea that might work.

Mawr 5y ago

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

jordanmaulana 5y ago

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..