Live data from Hacker News

How terrible code gets written by sane people

chrismm.com

121–130 of 151 posts

Re: How terrible code gets written by sane people

#121
post #103

I like the article but I found the implied solution a little humorous. Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and massochistic enough to stick it out at an obviously poorly run project. Good luck Side note, for 15 years of experience the project doesn't s…

I wrote two mails yesterday which basically "push back against upper management", for a very good reason. At least that's what I think. Now I'm totally terrified about what will happen tomorrow. I have 4 kids and almost no money in the bank.

In some companies this is respected more than people who just obey. I would potentially promote you and I know big corp execs who would too but could be that it is more common here.

Re: How terrible code gets written by sane people

#122
post #12

Earlier quoted context omitted.

There's an old quote I read and I keep it with me. It was for CEOs and it says, "You get what you incentivize." The hardest part of managing a group of people is incentivizing exactly what you want, yet so many people don't spend an ounce of thought tuning that properly. There's other people who believe process will fix everything, yet don't bother tuning their process. Many companies have fallen because the CEOs inc…

At our company we focus on intrinsic rewards rather than extrinsic rewards. We want people to feel good about the work they do, giving them the space and time to write quality code. We don't track any metrics such as commits or loc, heck we don't even track hours worked. We are much more interested in everyone, especially coders, focusing on what value their work brings to the end users. And how that syncs with the c…

You don't track hours worked? Do you have more or less fixed working hours? Otherwise how do you stop people staying a long time to impress the boss?

Re: How terrible code gets written by sane people

#123
post #81

Earlier quoted context omitted.

> The best ones are the ones that can push out a solution given too little time and given a (maybe self inflicted) bad code base. If every open source project was developed by those principles, all high and mighty web companies would collapse. Good work is being done , but it's for free. EDIT: You're right of course about the reality in the parasitic companies.

Sorry to disappoint. But despite the rare exception here and there most open source development is either paid or quickly forgotten. If I put into google "Linus Torvalds income" the first sentence reads: "Finnish-American software engineer and hacker Linus Torvalds has as estimated net worth of $150 million and an estimated annual salary of $10 million" Money.

https://pbs.twimg.com/media/B4Xo3CdCcAA2xm1.jpg

He has about $20 million[1], + cca $90k a year from the linux foundation [2].

[1] https://www.quora.com/How-rich-is-Linus-Torvalds [2] That he gets a salary from linux foundation: https://www.engadget.com/2007/01/22/the-linux-foundation-for... (doesn't say amount) I cannot find the hight of his salary now, but I read it somewhere.

Re: How terrible code gets written by sane people

#124
post #118
post #108

Earlier quoted context omitted.

Indented here-strings.

Nope, those require tabs. See first result on Google for "bash indented here string" as well as bash guide.

Yes they do. You must indent the here-string with tabs and not spaces (which sucks for people who prefer spaces). If you want to indent within the here-string, bash requires spaces and not tabs. Mixed spaces and tabs are required to get both kinds of indentation at the same time. A very common use case for this would be help text / usage strings.

Re: How terrible code gets written by sane people

#125
post #103

I like the article but I found the implied solution a little humorous. Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and massochistic enough to stick it out at an obviously poorly run project. Good luck Side note, for 15 years of experience the project doesn't s…

I wrote two mails yesterday which basically "push back against upper management", for a very good reason. At least that's what I think. Now I'm totally terrified about what will happen tomorrow. I have 4 kids and almost no money in the bank.

As long as you're tactful and willing to cede your argument if they don't come to see your side, there shouldn't be any reason to be terrified. If you act diplomatically and still have crazy bosses, might be good to find a different job if you can, or just not care and get your paycheck.

Re: How terrible code gets written by sane people

#126
post #51

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking a…

Agreed, but I would phrase it slightly differently. Moltke the Elder ( https://en.wikipedia.org/wiki/Helmuth_von_Moltke_the_Elder ) wrote that to understand military strategy you have to understand two basic things: - No plan survives contact with the enemy - Strategy is a system of expedients In other words, you can make all the plans you want, but as soon as you put them into action they have to take into account t…

I'd heard the quote about no plan surviving contact with the enemy but never bothered to look up the source. That is a great analogy, and I think you have restated a nice chunk of my working theory better than I did. Especially that an architecture is a hypothesis.

Under this framework, maybe I can reasonably suggest that software has at least 3 big enemies: customers, management, and the coders. We are one of the enemies, for lots of reasons, but in part because coding style fashion trends change quickly. One year everyone's using OO, classes with templates and separating their code and markup, the next year everyone's using composition instead of inheritance and smooshing their code and markup together and talking about how much better it is than the old ugly way.

People who didn't join a project at it's beginning tend to both complain about the bad practices disproportionately, and at the same time contribute to introducing new styles and making the codebase less consistent disproportionately. After a few of those, there's just no wonder that things start to look messy in any sizeable project.

Re: How terrible code gets written by sane people

#127
post #51

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking a…

> My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. If a code base doesn't change too much in side or original intent then architecture and design (if it was good in the first place and is continued to be followed) will probably keep it fairly maintainable. In a lot of cases though codebases slowly grow until they become of a…

> often you can be quite bound by the implementation specific behaviour of the original system

Yes, this. Requirements accumulate over time. That is what makes it harder to refactor production code to be cleaner. When you're not bound to your requirements, they can change, but when your requirements start to set in stone, you lose the freedom to change them.

Choosing to rewrite already released code is likely to introduce regressions, is more difficult than with unreleased code because you are not allowed to change requirements, and redoes work work that was already done once. If management is paying attention, they will (and should) complain about paying for the engineering again. After all this, there are no guarantees it won't just happen again. Things don't tend to stay magically clean after rewriting. That's assuming the rewrite even finishes cleanly. What often happens is the engineers underestimate the time to rewrite because they didn't understand how well and how many things were working, and it gets cut short by management a third of the way through when the rewrite is obviously over budget. Now the codebase is messier than when it started, even though the engineers had the best of intentions and management gave them large swaths of time to try and fix things.

Re: How terrible code gets written by sane people

#128
post #50
post #35

Earlier quoted context omitted.

A reviewer soon understands that senior devs are producing good code and stops investing time on reviewing their code. If they are doing their job properly. But again it comes down to internal motivation and self management on their part.

Yes, sorry I should have been more explicit. Initial reviews have value (is this guy full of beans or does he know what he's doing), but constant reviews of senior developer code do not. If you've hired anyone you have to constantly do reviews for, you've probably hired the wrong person. I mean they should get what you are looking for after a month or two.

You do need to make sure the changes follow the "philosophy" of whatever component is being changed. Otherwise you get things like duplicated functionality or APIs that don't have any cohesion. If the Senior engineer frequently works on this specific piece then its not an issue, but no matter how senior someone new to an area will not produce optimal code.

Re: How terrible code gets written by sane people

#129
post #51

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking a…

> My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens. By default, good code tends to be modular and easy to replace, while bad code is e…

> I wonder if one way around this is to force modularity, even when it's unnatural.

There's probably no denying this is a good idea. :) The most successful very large systems seem to be made of independent modules that each strive to do one thing well. They can also be more easily removed, refactored, or replaced, due to their small size, and perhaps most important you can do one at a time.

> I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens.

Yeah, it's true, emphasis at any given moment is on what list of things we want to see, and what list of things we don't want. The author even started with one. Problem is, code styles also change over time. What some people call reasonable or good code, other people call bad; "bad" is subjective. Hire a brilliant engineer to help make your decent application awesome, and her first reaction may be "oooh, this code is pretty bad. let's make some changes". I honestly wouldn't be able to count how many times I've seen the newest member of a project complain about the mess while nobody else seems to mind that much. (And I count myself in that list, I've done it too.)

Re: How terrible code gets written by sane people

#130
post #103

Earlier quoted context omitted.

I wrote two mails yesterday which basically "push back against upper management", for a very good reason. At least that's what I think. Now I'm totally terrified about what will happen tomorrow. I have 4 kids and almost no money in the bank.

As long as you're tactful and willing to cede your argument if they don't come to see your side, there shouldn't be any reason to be terrified. If you act diplomatically and still have crazy bosses, might be good to find a different job if you can, or just not care and get your paycheck.

Unfortunately it is not that simple. Sometimes pushing back on the management is an indication of misalignment of priorities. It may not happen right away, but it can definitely limit your tenure.

I have been on both sides of this.

Post reply on HN