Software engineers hate code
dancowell.com
Software engineers hate code
1–10 of 235 posts
Re: Software engineers hate code
#2Re: Software engineers hate code
#3Re: Software engineers hate code
#4Yea, mechanics love to complain about metric and imperial sizes and when they don’t thread in correctly, but at the end of the day a good mechanic loves seeing a smooth running car.
Similarly, a good software engineer loves it when they have a smooth running service. Updates work without hiccup and the system can be inspected to see how things are running. Having clean and maintainable code is directly proportional to the ease and pleasure of work on this service.
I believe in quality over quantity and I also believe that beautiful code exists. My hatred of code comes from lazy or rushed implementations, which can and should be improved over time.
LGTM culture is a product of bad management and should not be used as an excuse to ship lazy code or code written by people who hate what they do.
A good engineer should take pride in their work, even on the bad days. And even when the product itself isn’t what they would personally want.
Re: Software engineers hate code
#5Sometimes, they even are able to create codes that match such abstractions.
Sometimes, those abstractions are now flawed.
Sometimes, those abstractions are properly tooled.
Sometimes, the rest of the team also understands those abstractions.
The conjonction of all these rarely happen.
Re: Software engineers hate code
#6While the article resonates with me alot, I would like to, in the best spirit of the article, propose an addendum to that line:
When modifying existing code, do a very careful cost-benefit analysis; On the one side is the cost of a rebuild. On the other side is the projected cost of keeping this thing and maintaining it, not just for this change, but for changes in the forseeable future.
I realise that this is essentially an impossible requirement. We cannot forsee the future. But: We can make predictions. And when the predictions say, that, forseeably, the company will lose money down the line because we waited to long for a rebuild, it may be time to pitch that to whoever allocates resources.
Because, dragging a legacy-system along incurs it's own set of costs. This is especially true when it's not just maintained, but modified and extended. And many of those costs have a nasty tendency to remain hidden until they suddenly don't, and at that point, people often already expended inordinate amounts of resources on them.
So yeah, the first instinct should be: Use what already exists. But check the costs of doing so. Premature rebuilds are a waste of resources. And so is holding on to legacy systems past their expiration date.
Re: Software engineers hate code
#7Re: Software engineers hate code
#8Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my career. And it's a great thing -- both sorts of engineers are critical to a successful project.
Re: Software engineers hate code
#9This is like writing “mechanics hate bolts”. Yea, mechanics love to complain about metric and imperial sizes and when they don’t thread in correctly, but at the end of the day a good mechanic loves seeing a smooth running car. Similarly, a good software engineer loves it when they have a smooth running service. Updates work without hiccup and the system can be inspected to see how things are running. Having clean and…
What are you referring to specifically here? A culture where nobody is actually doing reviews and just LGTMing everything?
Re: Software engineers hate code
#10> Don't write new code when you can use, improve or fix what already exists. If you must write new code, write only what you need to get the job done. While the article resonates with me alot, I would like to, in the best spirit of the article, propose an addendum to that line: When modifying existing code, do a very careful cost-benefit analysis; On the one side is the cost of a rebuild. On the other side is the pro…
By the estimates of another team, it will take 2-3 months to build a wrapper around their codebase (it is that entangled) and throw that in EC2. The whole project will become infested with that codebase and those issues because as we all know, a “temporary fix” is never temporary. The codebase doesn’t cover anywhere near what we have in mind for features and extensibility is … yeah.