6 ms·

I've been consistently amazed at how far companies can get on shoddy code. In my experience, even majorly successful startups that turn into companies worth 10

I've been consistently amazed at how far companies can get on shoddy code. In my experience, even majorly successful startups that turn into companies worth 10's of billions tend to have lots of technical debt. Honestly, I believe that at some scale its very difficult to get the caliber of experience and talent that can keep a codebase clean. People often say accruing technical debt is a form of shortcutting to a more business focused goal, but in my experience the technical debt is almost always created by accident through lack of experience rather than a conscious tradeoff. Especially when you consider a SaaS company where your product lives forever and is meant to scale, taking on technical debt for short term gain is almost never the right decision. Not to reopen the 10x engineer debate, but I've observed that the top 20% of engineers tend to do 80% of the total work of an org. Of course, 10x is relative... But there are definitely individuals that are 10x more productive than the median engineer. And for whatever reason, that seems more to do with an individual's personality and drive than their level of experience... Though of course experience helps. Especially as a project scales, somebody who makes good technical decisions will only increase the productivity margin between themselves and others. What I see in a lot of these SaaS codebases is that it takes a week to do something that should take 1 day, due to amount of technical debt and spaghetti code. Software is still a new industry. I fully believe the companies that win in the long run will be the ones that have the best codebases (assuming software is what differentiates your business). The impact that it has on velocity is just monumental. Code quality and philosophy of well written code is not stressed at all in school... One example of how far off we are from maturity as a discipline. There is a whole school of thought that's currently neglected that will become mainstream in the future IMO. Similar to other engineering disciplines...

vsareto 6y ago
If the 10x and gatekeeping people want to give us methods for getting to 10x productivity/skill, I'm all for it. But articles and threads like these always fail to give up a method of reliably training that quality and accurately testing for it. Until I can hold up a plaque where humanity agrees that I'm a proven 1x, 5x, or 10x engineer and I deserve money and a job according to each of those levels, it's all just posturing and debate.
- adam_arthur 6y ago
  Unfortunately I'm not sure it's trainable. It seems much more correlated to an individual's personality and drive. The traits I see in engineers who I consider to be 10x: Growth mentality. Always try to do things the "right way" rather than just completing a task. Educate yourself via internet/books to understand all points of view on an issue, and tradeoffs of each approach. Setting a high bar for your work. Never solely focus on getting the job done, always question and focus on what the best way to get the job done is. Extremely self critical. Don't get attached to your work. Always criticize yourself and question whether decisions you made were correct. Objectivity. Always quantify objectively to yourself why you made a given design decision, why did you name your variable X vs Y? Could you justify the merits of your approach to others without relying on subjective points? Focus on business value. Optimize for what drives business value. Don't pursue projects that are technically interesting that don't provide long run value, for example. Work with intensity. These people legit code 8-10 hours a day straight. They aren't coding for 30m then browsing the internet. Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution. Self managing. Can operate 100% independently without constant manager intervention. High level direction still important to align on business goals of course. Ownership. These people take pride in their work and feel a sense of ownership over their code. They don't need to be asked to step in when something they've worked on has an issue. It's not about specific knowledge at all, or training. People could learn to follow these principals, but it's much easier when it's in your nature. I have not seen anyone really change their trajectory from median to superstar before, but I'm sure it's possible with a mentality shift.
  - fctorial 6y ago
    > These people legit code 8-10 hours a day straight. That's physically impossible, unless you're performing some assembly line task like creating a frontend prototype from a marvelapp mock (tons of html, css, js). Can you do creative work for 10 hours in a stretch, every day.
    - adam_arthur 6y ago
Clubber 6y ago
>I've been consistently amazed at how far companies can get on shoddy code. I think this was one of the most disheartening realizations of my career. I spent and still spend a lot of thought on how to improve code for readability and maintainability just to realize companies can make a lot of money with crap for a long time.
- jbluepolarbear 6y ago
  This is where I shine in start up environments. I can throw together “working” implementations quickly while also having the forward thought to allow the system to be incrementally replaced or improved overtime. My starting implementations can look rough and sloppy, but I use consistent patterns and designs that guide building out more complex systems as we go. I have also done the opposite of taking an existing monolithic spaghetti code system and start isolating functionality without changing behavior. This then allows to improve and replace sub systems as needed.
- adam_arthur 6y ago
  I think it's more of a correlation not causation thing :) All else equal, the company with the better codebase will be more competitive/make more money. But at the same time it's just true that for most companies code quality and technical excellence are not core qualities of their culture. A lot of companies say that it is, but they don't live it... Or the original founder/technical team don't really have the chops to enforce that quality and make it a core element of the business. Of course that doesn't meant they're not smart. I've known a huge number of highly intelligent people that don't care about code quality, or the future human reader. Needs to become embedded in culture of the org for it to trickle down and become lived in practice.
bumby 6y ago
So many good points in this post. But I’ll nit pick this one anyway :-) >technical debt is almost always created by accident through lack of experience rather than a conscious tradeoff. I agree with this, at least early on in the business. But my experience is that many organizations eventually realize their technical debt. Sometimes the realization comes so far down the line that it feels like a monumental task to fix and then it does become a conscious decision. “We know the code base is shoddy and needs to be fixed, but the schedule/cost risk outweighs the quality risk.” >Software is a new industry In the early 1990s I heard it referred to as the “cave drawing days” of the industry. I wonder if it’s similar to how mechanical systems were in the early days of the industrial revolution. Lots of innovation, very few codified best practices related to pressure systems etc. It seems like the steam era of “move fast and break things”. Eventually, industry caught up and put together standards like ASME codes (or were regulated to do so). I’d like to see this more commonplace in software beyond its current adoption in a few industries
wildmanx 6y ago
Part of the problem is that "well written code" is unbelievably subjective. Take 10 people from hacker news and you will get 10 likely very different answers, some of them most likely the exact opposites. Maybe it has to do with being "a new industry", but by now we have accumulated decades. I think it's more because you can get away with it. In other industries, you can't. If a bridge collapses, people die. If a car's brakes fail, people die. If you administer the wrong amount of anesthesia, people die. If you write spaghetti code .. shrug and move on. Even within the code base of the place I work in, a few hundred sw engs in total, we don't have a shared understanding of what exactly "good", "clean", ... design is. Everybody has an idea, and there are overlaps, but the criteria that people seem to optimize for, and thus the conclusions they draw about design, differ vastly. Within my company, and even more so across our industry.
- catlifeonmars 6y ago
  Heh, good code is the kind you can throw away once you’ve used it to sell stakeholders on an idea. It’s contextual. Or, to put it another way: is a very structurally sound bridge located on a road that no one uses considered a “good” bridge?
  - Grimm1 6y ago
    I'd raise a difference between good and useful then. That is still a good bridge, but it's not a useful one. I think that also transfers to programming. That also raises that what makes a bridge good is not usefulness it's perhaps structural quality. Maybe the only thing that makes programming good is usefulness in which case my point is moot.
- adam_arthur 6y ago
  There's subjectivity, but you can also certainly make objective arguments for why one form is readable relative to others. For example, here are some principles I can strongly justify: Bubble important info. Structure your code visually such that signal to noise ratio is highest. E.g. appropriately named variables should be more immediately visible than implementation details. E.g. if variable is named well, you can typically ignore the RHS of an assignment... It's an implementation detail. Don't indent such that RHS of assignment is emphasized. We can debate that point, but I'm using objective reasoning for defining why this style is beneficial. Human readable naming. Name of variables should define exactly what they represent and nothing else. Your code should be written to read as closely to natural language as possible. E.g. if in a functional language, and all functions describe what they do exactly, RHS of assignments are indented to deemphasize them, you can understand high level of any function quickly by scanning LHS assignments and top level expressions. The more unclear your names, the more "mental recalls or lookups" the reader has to do. Don't use anonymous functions. For anything longer than one line, always used a named function that appropriately represents what it does. Reader should not ever get implementation details pushed into their face. Pushing implementation details to the forefront is the biggest readability error I see in code. It's almost never important for business oriented code unless there's a bug in it. Majority of the time the reader is simply trying to get context and understand meaning of the code. Optimize for this. Hide your declared functions out of sight. Reader will get high level understanding of their use where called, due to their name. If they want to reference the implementation, they can go to function declaration, but typically they won't need to. Don't declare functions sibling to your core logic. They should not break high level flow of function (does not help readability). Frustrating when people declare functions above where the core logic of the function is... See it a lot in python due to lack of inner function hoisting. Books have footnotes for a reason Hide implementation details as much as possible behind api boundaries. Model component apis such that implementation details are not exposed to caller or creator. Don't mix naming of business concepts and render logic. E.g. if you have a generic graph component, nothing within that component should reference your business domain. I see this mistake a lot. More generally, never name something which implies an understanding of a different context than the one you're in. By doing so you're coupling the two domains and increasing the amount of context the reader needs to understand your code. Prefer immutable variables. The more constants and immutable state you use, the fewer things you have to track in your head as you follow code. You know once you see an assignment, that variable will never change. You don't need to scan every line between assignment and later use to determine whether that var is later modified. Don't nest expressions too deeply, such that it's difficult to parse. If you can instead assign to appropriately named variable, reader can typically ignore the expression altogether. Prefer named function or variable that describe the result of a computation rather than inlining an expression. If featureFlag == 1 represents isFeatureEnabled, assign that to an appropriately named variable. Anytime you make the reader "infer the name" of a variable by parsing the expression themselves, you make your code harder to read. camelCase is superior to snake_case because a variable represents a single concept, not separate concepts represented by a string of words. Adding underscore unnecessarily makes words visually distinct when you're dealing with a single concept. They also add verbosity and length that doesn't benefit anything. Is there an objective argument for snake case being more readable other than it's the convention in some languages (not objective reasoning) (Flame war go!) Anyway, I could go on with a number of more points. Am I suggesting there's a correct style? Not at all. But you can absolutely use strong and objective reasoning for why one style is superior to another. I don't see people typically apply this kind of rigor to their style, they tend to just prefer one approach "because". Different people will weight things differently, so can come to different conclusion given same evidence, but there's absolutely a whole set of philosophy and logic you can use to justify style, and it's not explored at all in academia really. Final note. There is definitely an element of cultural bias as well. People who tend to read code of one style will more readily be able to parse that style. There is no universal truth. But if we all start from the same state, we should justify which styles are best with strong reasoning.
gorbachev 6y ago
>Software is still a new industry. I fully believe the companies that win in the long run will be the ones that have the best codebases (assuming software is what differentiates your business). There are so many counter examples (Facebook, Microsoft to name two) to your point it simply can not be true.
- adam_arthur 6y ago
  So your view is that the long run is a few decades? :) When I say long run, I'm talking hundreds of years. Software as an industry is not even one generation old yet. There are countless advancements that will come. That being said, I don't consider social networks to fall into the class of an area where your product is the main differentiator. Network effects come first, product second. Database products are a better example. JIRA another. It's the most widely used now but extremely slow and buggy. I sincerely doubt JIRA will be the winner 100 years from now if they don't improve technically. In fact, a lot of software companies these days are just competing with traditional companies, but with better software. That's the whole selling point. E.g. fintech replacing banks, uber replacing taxis, insurance companies that make it easy to make claims etc. The bigger the tech disparity, the bigger the advantage. Lets see!
  - PaulDavisThe1st 6y ago
    > So your view is that the long run is a few decades? :) I suspect that there's almost nothing going on at the Ford Motor Company that has even the remotest connection to anything technical that happened during the early years of the company's founding. Sometimes, stuff just really does age out.
    - stevegalla 6y ago
      I guess it depends on how much leeway you can be given for using “almost nothing” and “remotest connection to anything technical”, but Wikipedia says Ford Motor Company was incorporated in 1903 and the first assembly line dates to 1913. Engine blocks are still cast, sheet metal is still bent, pressed, and rolled so I think there is a lot of the original years still around. Yes, I’ll give you that there have been huge advances in sophistication, but it seems to me the early years are still present.
com2kid 6y ago
> Especially as a project scales, somebody who makes good technical decisions will only increase the productivity margin between themselves and others. I once saw a customer obsessed junior engineer push out features that our users really wanted, but that none of the senior engineers had time for. Half a year or so later one of the senior engineers was complaining that he had to rewrite everything that junior engineer did due to how poorly the code was written. End of the day? The junior engineer's code is what got shipped and made the user's happy. Was it tech debt that had to be rewritten? Sure. Was my team happy with him for being willing to work with us to make the product better? Yup. Perfect is the enemy of the good and all that. (I've also seen code where changes took a long time because someone invented a DI framework and layers of XML configuration files when a single if statement with 2 branches would've done the trick. Was the solution well engineered? Yes! Very reliable, good quality code. Took me a few days to get ahold of it and add that 2nd conditional...)
- adam_arthur 6y ago
  Sure, but if a senior engineer had written it in the first place, it wouldn't have had to be rewritten, thus saving lots of time (assuming senior engineer is strong technically :)) If you had instead hired an additional senior guy who was paid 1.5x compared to the junior guy, it would have been a better outcome for the business all around. Of course just using this contrived example, and the exact salary numbers change the outcome...
  - com2kid 6y ago
    We had plenty of senior engineers, they were busy doing senior engineering things! Sometimes not knowing something is supposed to be hard is what makes that hard thing possible to do.
  - hnedeotes 6y ago
    I value code well written, maintainable, and testable but sometimes I'm a bit put off on certain conclusions. Once I read a report by a guy who had come in into a business to re-work an, by his words, unmaintainable mess. This had been written over five years by a single guy and no-one seemed to be able to make sense of it. The one re-writing touted what they had accomplish, a full re-write with a team of 15 or so people, in a couple months. I can believe that some guys are dickheads and do crap and are anti-social or don't want anyone touching their stuff and think they're the last cookie in the packet. On the other hand, there's a real difference between writing from scratch something, with features tacked on week-in week-out, contradicting requests, no time to work through issues or problems, being the only one allocated to the problem and having no real plan or feature map laid out, during 5 years and then coming in, when all the system is laid out, all the bugs and domain knowledge have been made visible, there's a working system that can be used as base to understand the objectives, the rough edges, problems and pain points are also known, and rewriting it from scratch better. Lastly, it's also not known if they had been the ones writing from start with the same constraints if it would have been so pristine as they claim, and it hasn't stood the time for 5 years yet. Maybe it'll end problematic as well but now it took a team of 15 or so that probably cost more than that single guy for 5 years - and still made something that helped keep the business throughout.

vsareto 6y ago

If the 10x and gatekeeping people want to give us methods for getting to 10x productivity/skill, I'm all for it. But articles and threads like these always fail to give up a method of reliably training that quality and accurately testing for it. Until I can hold up a plaque where humanity agrees that I'm a proven 1x, 5x, or 10x engineer and I deserve money and a job according to each of those levels, it's all just posturing and debate.

adam_arthur 6y ago
Unfortunately I'm not sure it's trainable. It seems much more correlated to an individual's personality and drive. The traits I see in engineers who I consider to be 10x: Growth mentality. Always try to do things the "right way" rather than just completing a task. Educate yourself via internet/books to understand all points of view on an issue, and tradeoffs of each approach. Setting a high bar for your work. Never solely focus on getting the job done, always question and focus on what the best way to get the job done is. Extremely self critical. Don't get attached to your work. Always criticize yourself and question whether decisions you made were correct. Objectivity. Always quantify objectively to yourself why you made a given design decision, why did you name your variable X vs Y? Could you justify the merits of your approach to others without relying on subjective points? Focus on business value. Optimize for what drives business value. Don't pursue projects that are technically interesting that don't provide long run value, for example. Work with intensity. These people legit code 8-10 hours a day straight. They aren't coding for 30m then browsing the internet. Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution. Self managing. Can operate 100% independently without constant manager intervention. High level direction still important to align on business goals of course. Ownership. These people take pride in their work and feel a sense of ownership over their code. They don't need to be asked to step in when something they've worked on has an issue. It's not about specific knowledge at all, or training. People could learn to follow these principals, but it's much easier when it's in your nature. I have not seen anyone really change their trajectory from median to superstar before, but I'm sure it's possible with a mentality shift.
- fctorial 6y ago
  > These people legit code 8-10 hours a day straight. That's physically impossible, unless you're performing some assembly line task like creating a frontend prototype from a marvelapp mock (tons of html, css, js). Can you do creative work for 10 hours in a stretch, every day.
  - adam_arthur 6y ago

Clubber 6y ago

>I've been consistently amazed at how far companies can get on shoddy code. I think this was one of the most disheartening realizations of my career. I spent and still spend a lot of thought on how to improve code for readability and maintainability just to realize companies can make a lot of money with crap for a long time.

jbluepolarbear 6y ago
This is where I shine in start up environments. I can throw together “working” implementations quickly while also having the forward thought to allow the system to be incrementally replaced or improved overtime. My starting implementations can look rough and sloppy, but I use consistent patterns and designs that guide building out more complex systems as we go. I have also done the opposite of taking an existing monolithic spaghetti code system and start isolating functionality without changing behavior. This then allows to improve and replace sub systems as needed.
adam_arthur 6y ago
I think it's more of a correlation not causation thing :) All else equal, the company with the better codebase will be more competitive/make more money. But at the same time it's just true that for most companies code quality and technical excellence are not core qualities of their culture. A lot of companies say that it is, but they don't live it... Or the original founder/technical team don't really have the chops to enforce that quality and make it a core element of the business. Of course that doesn't meant they're not smart. I've known a huge number of highly intelligent people that don't care about code quality, or the future human reader. Needs to become embedded in culture of the org for it to trickle down and become lived in practice.

bumby 6y ago

So many good points in this post. But I’ll nit pick this one anyway :-) >technical debt is almost always created by accident through lack of experience rather than a conscious tradeoff. I agree with this, at least early on in the business. But my experience is that many organizations eventually realize their technical debt. Sometimes the realization comes so far down the line that it feels like a monumental task to fix and then it does become a conscious decision. “We know the code base is shoddy and needs to be fixed, but the schedule/cost risk outweighs the quality risk.” >Software is a new industry In the early 1990s I heard it referred to as the “cave drawing days” of the industry. I wonder if it’s similar to how mechanical systems were in the early days of the industrial revolution. Lots of innovation, very few codified best practices related to pressure systems etc. It seems like the steam era of “move fast and break things”. Eventually, industry caught up and put together standards like ASME codes (or were regulated to do so). I’d like to see this more commonplace in software beyond its current adoption in a few industries

wildmanx 6y ago

Part of the problem is that "well written code" is unbelievably subjective. Take 10 people from hacker news and you will get 10 likely very different answers, some of them most likely the exact opposites. Maybe it has to do with being "a new industry", but by now we have accumulated decades. I think it's more because you can get away with it. In other industries, you can't. If a bridge collapses, people die. If a car's brakes fail, people die. If you administer the wrong amount of anesthesia, people die. If you write spaghetti code .. shrug and move on. Even within the code base of the place I work in, a few hundred sw engs in total, we don't have a shared understanding of what exactly "good", "clean", ... design is. Everybody has an idea, and there are overlaps, but the criteria that people seem to optimize for, and thus the conclusions they draw about design, differ vastly. Within my company, and even more so across our industry.

catlifeonmars 6y ago
Heh, good code is the kind you can throw away once you’ve used it to sell stakeholders on an idea. It’s contextual. Or, to put it another way: is a very structurally sound bridge located on a road that no one uses considered a “good” bridge?
- Grimm1 6y ago
  I'd raise a difference between good and useful then. That is still a good bridge, but it's not a useful one. I think that also transfers to programming. That also raises that what makes a bridge good is not usefulness it's perhaps structural quality. Maybe the only thing that makes programming good is usefulness in which case my point is moot.
adam_arthur 6y ago
There's subjectivity, but you can also certainly make objective arguments for why one form is readable relative to others. For example, here are some principles I can strongly justify: Bubble important info. Structure your code visually such that signal to noise ratio is highest. E.g. appropriately named variables should be more immediately visible than implementation details. E.g. if variable is named well, you can typically ignore the RHS of an assignment... It's an implementation detail. Don't indent such that RHS of assignment is emphasized. We can debate that point, but I'm using objective reasoning for defining why this style is beneficial. Human readable naming. Name of variables should define exactly what they represent and nothing else. Your code should be written to read as closely to natural language as possible. E.g. if in a functional language, and all functions describe what they do exactly, RHS of assignments are indented to deemphasize them, you can understand high level of any function quickly by scanning LHS assignments and top level expressions. The more unclear your names, the more "mental recalls or lookups" the reader has to do. Don't use anonymous functions. For anything longer than one line, always used a named function that appropriately represents what it does. Reader should not ever get implementation details pushed into their face. Pushing implementation details to the forefront is the biggest readability error I see in code. It's almost never important for business oriented code unless there's a bug in it. Majority of the time the reader is simply trying to get context and understand meaning of the code. Optimize for this. Hide your declared functions out of sight. Reader will get high level understanding of their use where called, due to their name. If they want to reference the implementation, they can go to function declaration, but typically they won't need to. Don't declare functions sibling to your core logic. They should not break high level flow of function (does not help readability). Frustrating when people declare functions above where the core logic of the function is... See it a lot in python due to lack of inner function hoisting. Books have footnotes for a reason Hide implementation details as much as possible behind api boundaries. Model component apis such that implementation details are not exposed to caller or creator. Don't mix naming of business concepts and render logic. E.g. if you have a generic graph component, nothing within that component should reference your business domain. I see this mistake a lot. More generally, never name something which implies an understanding of a different context than the one you're in. By doing so you're coupling the two domains and increasing the amount of context the reader needs to understand your code. Prefer immutable variables. The more constants and immutable state you use, the fewer things you have to track in your head as you follow code. You know once you see an assignment, that variable will never change. You don't need to scan every line between assignment and later use to determine whether that var is later modified. Don't nest expressions too deeply, such that it's difficult to parse. If you can instead assign to appropriately named variable, reader can typically ignore the expression altogether. Prefer named function or variable that describe the result of a computation rather than inlining an expression. If featureFlag == 1 represents isFeatureEnabled, assign that to an appropriately named variable. Anytime you make the reader "infer the name" of a variable by parsing the expression themselves, you make your code harder to read. camelCase is superior to snake_case because a variable represents a single concept, not separate concepts represented by a string of words. Adding underscore unnecessarily makes words visually distinct when you're dealing with a single concept. They also add verbosity and length that doesn't benefit anything. Is there an objective argument for snake case being more readable other than it's the convention in some languages (not objective reasoning) (Flame war go!) Anyway, I could go on with a number of more points. Am I suggesting there's a correct style? Not at all. But you can absolutely use strong and objective reasoning for why one style is superior to another. I don't see people typically apply this kind of rigor to their style, they tend to just prefer one approach "because". Different people will weight things differently, so can come to different conclusion given same evidence, but there's absolutely a whole set of philosophy and logic you can use to justify style, and it's not explored at all in academia really. Final note. There is definitely an element of cultural bias as well. People who tend to read code of one style will more readily be able to parse that style. There is no universal truth. But if we all start from the same state, we should justify which styles are best with strong reasoning.

gorbachev 6y ago

>Software is still a new industry. I fully believe the companies that win in the long run will be the ones that have the best codebases (assuming software is what differentiates your business). There are so many counter examples (Facebook, Microsoft to name two) to your point it simply can not be true.

adam_arthur 6y ago
So your view is that the long run is a few decades? :) When I say long run, I'm talking hundreds of years. Software as an industry is not even one generation old yet. There are countless advancements that will come. That being said, I don't consider social networks to fall into the class of an area where your product is the main differentiator. Network effects come first, product second. Database products are a better example. JIRA another. It's the most widely used now but extremely slow and buggy. I sincerely doubt JIRA will be the winner 100 years from now if they don't improve technically. In fact, a lot of software companies these days are just competing with traditional companies, but with better software. That's the whole selling point. E.g. fintech replacing banks, uber replacing taxis, insurance companies that make it easy to make claims etc. The bigger the tech disparity, the bigger the advantage. Lets see!
- PaulDavisThe1st 6y ago
  > So your view is that the long run is a few decades? :) I suspect that there's almost nothing going on at the Ford Motor Company that has even the remotest connection to anything technical that happened during the early years of the company's founding. Sometimes, stuff just really does age out.
  - stevegalla 6y ago
    I guess it depends on how much leeway you can be given for using “almost nothing” and “remotest connection to anything technical”, but Wikipedia says Ford Motor Company was incorporated in 1903 and the first assembly line dates to 1913. Engine blocks are still cast, sheet metal is still bent, pressed, and rolled so I think there is a lot of the original years still around. Yes, I’ll give you that there have been huge advances in sophistication, but it seems to me the early years are still present.

com2kid 6y ago

> Especially as a project scales, somebody who makes good technical decisions will only increase the productivity margin between themselves and others. I once saw a customer obsessed junior engineer push out features that our users really wanted, but that none of the senior engineers had time for. Half a year or so later one of the senior engineers was complaining that he had to rewrite everything that junior engineer did due to how poorly the code was written. End of the day? The junior engineer's code is what got shipped and made the user's happy. Was it tech debt that had to be rewritten? Sure. Was my team happy with him for being willing to work with us to make the product better? Yup. Perfect is the enemy of the good and all that. (I've also seen code where changes took a long time because someone invented a DI framework and layers of XML configuration files when a single if statement with 2 branches would've done the trick. Was the solution well engineered? Yes! Very reliable, good quality code. Took me a few days to get ahold of it and add that 2nd conditional...)

adam_arthur 6y ago
Sure, but if a senior engineer had written it in the first place, it wouldn't have had to be rewritten, thus saving lots of time (assuming senior engineer is strong technically :)) If you had instead hired an additional senior guy who was paid 1.5x compared to the junior guy, it would have been a better outcome for the business all around. Of course just using this contrived example, and the exact salary numbers change the outcome...
- com2kid 6y ago
  We had plenty of senior engineers, they were busy doing senior engineering things! Sometimes not knowing something is supposed to be hard is what makes that hard thing possible to do.
- hnedeotes 6y ago
  I value code well written, maintainable, and testable but sometimes I'm a bit put off on certain conclusions. Once I read a report by a guy who had come in into a business to re-work an, by his words, unmaintainable mess. This had been written over five years by a single guy and no-one seemed to be able to make sense of it. The one re-writing touted what they had accomplish, a full re-write with a team of 15 or so people, in a couple months. I can believe that some guys are dickheads and do crap and are anti-social or don't want anyone touching their stuff and think they're the last cookie in the packet. On the other hand, there's a real difference between writing from scratch something, with features tacked on week-in week-out, contradicting requests, no time to work through issues or problems, being the only one allocated to the problem and having no real plan or feature map laid out, during 5 years and then coming in, when all the system is laid out, all the bugs and domain knowledge have been made visible, there's a working system that can be used as base to understand the objectives, the rough edges, problems and pain points are also known, and rewriting it from scratch better. Lastly, it's also not known if they had been the ones writing from start with the same constraints if it would have been so pristine as they claim, and it hasn't stood the time for 5 years yet. Maybe it'll end problematic as well but now it took a team of 15 or so that probably cost more than that single guy for 5 years - and still made something that helped keep the business throughout.