Live data from Hacker News

Software engineers hate code

dancowell.com

201–210 of 235 posts

Re: Software engineers hate code

#201
post #8

> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except 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 ca…

Sure. Of course there are actually software developers out there in the world that read and write code. After all, that's where all this software in the world actually comes from. But for the other 85+% of people in the profession its basically a game of AdLibs. Fill in the blank. That's why there is such heavy reliance on things like frameworks, dependencies, and Invented Here Syndrome (people who don't trust their…

I think this is an orthogonal point. Certainly there are lots of bad developers in the industry whose code appears to only work by accident. But there are just as many of them doing greenfield projects as maintenance tasks. In fact, I would guess that in growth-oriented companies there are far more of these bad developers doing greenfield projects.

The issue is that in many companies there is constant pressure from management to "innovate" by building new features or new products, even if they are of no particular utility. New stuff will bring new customers (or new subscriptions from old customers) and that will either make you personally rich, or at least look good on your CV so you can leverage the experience into the next job where you can get rich. And if the project fails, it still leaves you looking more valuable to the top brass than the people who quietly kept the systems running, because you took risks and had big ideas and showed a growth mindset.

I didn't really notice this at the start of my career, but once you see the pattern it makes so many jobs incredibly depressing. People just keep building more and more crap to advance their careers and enrich the shareholders, even when very little of it is actually useful. It's even more depressing in B2C where it becomes apparent that a large part of the money comes from exploiting individuals who simply get a buzz from buying new stuff, no matter what that stuff does or how good it is.

Personally, I am much more happy to work on an established system that already has real customers that value what it does. The phase of throwing huge amounts of crap at the wall to see what sticks is over, so what remains is an actually-useful piece of software that's full of bugs and superfluous functionality that the "innovators" (comprised of both good and bad developers) left behind. I think it's worth it to have good engineers dedicated to this role of taking the mess and refining it into the best version of the thing that customers actually want. Leaving that task to the bad developers will just result in the system eventually collapsing, which might not matter to the entrepreneurial types who only care about growth, but it does matter to the customers who were getting value from it.

Re: Software engineers hate code

#202
post #174

Earlier quoted context omitted.

Pieces of art are repurposed all the time, I am sure Nietzsche took it from somebody living even further back in the past.

Ecclesiastes 1:9 “The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun.”

Love Ecclesiastes, hands down the best bit of poetry in The Book.

Also "Of making many books there is no end, and much study is a weariness of the flesh" way before it exponentiated to the moon ...

Honourable mention to "For everything there is a season", as sung by The Byrds.

Re: Software engineers hate code

#203

Earlier quoted context omitted.

I think it's a spectrum. For example I like writing new code and designing new things, but I don't hate or dislike my or other people's old code. That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice. It might not be good code, by our standards, but who knows how it was written. Was the author under stress, under time obligations, or happy, or somethin…

> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice. Small piece of advice: it is much better to learn how to take criticism of your code as exactly that - it's criticism of your code. People will always be unkind when reviewing code. Even if it's the best code ever written someone will have a different opinion and express it in a seemingly unkind…

I agree so strongly with this. It’s all about the code! You need a tough skin in this game, and the ability to seperate emotion from the end goal “good code!”.

I love the Eastern European approach; blunt and to the point. The French are also good for this. We anglos are so sensitive, and so afraid of offending, that you end up with a silly inefficient dance. “Have you considered? Perhaps if we tried this approach…”. No! Give me “this won’t work, do it this way” every time!

Re: Software engineers hate code

#204
post #8

> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except 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 ca…

My experience is that people who love writing new projects are probably not well suited for it. It means they aren't stressing over the ambiguities and long-term consequences of every single architectural decision, and thus are more likely to produce a project that immediately suffers from many technical issues, such as scaling, performance, ease of monitoring/debugging, ease of extension, ease of onboarding new maintainers, etc.

Start your project on the right foot by finding that disgruntled senior engineer and giving them ample time for design and research.

Re: Software engineers hate code

#206
post #180
post #27

Earlier quoted context omitted.

Indeed! This phenomenon has been a great source of freelancing customers for me. Startups naturally thrive on an early team that loves building new things, but the flip side is that they rarely seem to go back to fix existing stuff. That leaves a gap for people like me, who prefer to take something that works poorly and make it bulletproof. For some reason this quite often seems to involve db access patterns but ther…

Out of curiosity, how do you go about finding clients for this kind of work?

Most of my clients were from a local meetup where I eventually got to know most people quite well and they me. It was mostly word-of-mouth where people remembered "Oh! had similar problems and WJW solved it for them".

Re: Software engineers hate code

#207

Using a house analogy, I don't hate other people's houses. I hate it when other people blow a hole in the side of my house to put in a new window. They blasted a hole through two walls because it was the quickest way. Then just taped some plastic over the second hole. The project manager said it's still summer and we don't really need that wall at the moment. I know who will have to fix the wall when the winter comes…

That's an organizational issue. Code that does such things would not pass review unless it were specifically a requirement (or if your team is disogranized).

Once you're a senior dev, you start to look at the project holistically, adding your input to the design in order to ensure that the project serves its objectives. The code is still important, sure, but the success of the project is more important (and that can sometimes involve some short-term ugly changes).

If there's a business need for a hole in the side of the house covered with plastic that will probably be there for the next year, it's expected that you've all had many meetings discussing this modification and its necessity. By the time the code changes come, you've either long agreed with the reasoning, or have agreed to hold your tongue, or have started shopping out your resume.

Regardless, by the point this code is written, you'll already be expecting it and won't be blaming the dev who wrote it.

Re: Software engineers hate code

#208
It’s because you can only understand why things are structured the way they are, if you go on the journey from scratch yourself.

It would probably be easier if there was a video or scrubber/slider to see how the code evolved.

So many times you look at something and go: why is this so complex. Could be simpler. And you miss an edge case that causes the need for the complexity/abstraction. There are times too though that after a refactor someone can’t see some redundancy or is hanging onto an abstraction that looks great but is unnecessary.

Re: Software engineers hate code

#209
I loved this article! In the end, it is exactly to the point: code adds and adds complexity; complexity we hate. At the same time, complexity comes from our flawed knowledge, and only true knowledge gained in battles shows us simple ways. Simple ways bring us joy.

Re: Software engineers hate code

#210
post #114

Earlier quoted context omitted.

The key is identifying which parts of the code needs to be adapted or replaced and which do not. If the code is well designed with separation of concerns, replacing a framework or library or external dependency should not require all the code to be scrapped, just the layers directly interacting with replaced part. Some trivial applications are basically just glue between frameworks, but most non-trivial application o…

> If the code is well designed with separation of concerns, "If" is the operative term here. "If" it is well designed, then there is usually not alot of reason to scrap it in the first place.

Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either, for the same reasons which caused the scrapped version to be badly designed.

It is even likely the new version will be worse, since it wont be developed incrementally, and that harsh deadlines will be imposed when the organization realize they can't evolve the product as long as the ground-up rewrite is underway.

Post reply on HN