The Problem You Solve Is More Important Than the Code You Write | Hacker News Reader

The Problem You Solve Is More Important Than the Code You Write

levelup.gitconnected.com

35 pointstreyhuffine11 comments

I was at a conference a few weeks ago and one speaker put up a slide that went something like:

“Software engineers solve problems. Sometimes they solve problems with code.”

Which is how I’ve always viewed my role, but it has definitely become clearer over my 20 years in the business of software that there are a ton of people who just want to sit in a corner and write beautiful elegant code with no particular purpose. Great for personal projects. Troublesome when you are building a team to solve business goals.

I agree and have noticed the same thing. Some engineers won't turn in code unless it's perfect which can be at the detriment of the company.

If the code is being written/problem solved is for your job, you need to come up with the solution has the most business value and impact, not just spend the time to write the best code that will also happen to solve the problem.

Here on HN there are many articles (some even today) ranking where people hammer on about performant code and database queries; never do this, don’t use ORMs etc without even knowing any business case they are referring to. People are calling out for people to ‘tweak, optimize and refactor’ without knowing anything about what the reader might be doing. I find that quite a solid case of people doing things they maybe should not be doing while spending a lot of time on these things.

If ‘beautiful, highly optimized’ code is not a business goal then I am wondering what money they are burning; if not their own, it could be very worrying for the company.

Ok, beautiful and highly optimized code needs to be a standard in my opinion. If it is genuinely well written, it simultaneously teaches new comers good habits (implicit training), and makes future modifications that much easier. These are time savers. Time is money. It is a money saver.

Conclusion: Beautiful and optimized code is a money saver.

One addendum: Optimized code results in a performant application. This means you are better than a competing product that accomplishes the same thing but at a slower speed. You've maybe heard: 'performance is a feature' for this reason. This, one COULD argue, is a direct money maker.

You can then tack on words like 'slick', 'snappy', etc. to your list of descriptors.

The problem is beauty is in the eye of the beholder. I've been around long enough to see a few cycles of "best thing ever" -> "never do this". Each time massive disruptive changes were done to the code base, and each time they were simply ripping out last cycle's fad.

Certainly there are new things under the sun, but one should try and be respectful of what has come before. It wasn't all crap.

Your response kinda makes the point the article was trying to make.

This made me realize I am the problem at my workplace. I honestly could not care less about our product. Initially I was there for the money, now because of the sense of responsibility. But, I’m hurting the company more with me staying and being this person I’ve started to hate.

The closer I'm getting to a release version of my side-project, artjutsu, the more I realize that the code is just gonna be an ugly ugly mess. I could take the time to make it beautiful, but that's not helping anyone. Not at the moment.

I feel that I'd rather have some un-easy code that is not optimized so that I can have something cool for people to use. Besides, if its successful, I could go look back and make it optimized and beautiful.

Getting things done is what matters (at least for me at this point).

I keep telling myself I will refactor....but I rarely feel like it because I would rather work on a new exciting project. In the end, I still learn a lot, and I usually will refactor when a bug is discovered.

Same here.

I'm currently working on a part of the site where it should be refactored, but I chose not to because I just want to get the functionality to work. Once its good, I'll find the similarities and then refactor.

I'm also an artist, musician, and an athlete. I see similarities with those things and coding. In order to improve, you have to go through the "fog". That is, go with a concept , get messy, and see it through.

In the "fog" I tend to second guess myself and feel I'll never get out of it. But in the end things tend to work itself out and I'm better for it. After 10 pictures drawing the same thing, the 11th one is almost always better. Same with coding. I find myself looking 3-4 steps ahead and eventually write better code because of it. All just from working on and seeing through projects.

This depends on if you are writing code for others, a company or yourself. If you're writing code for others as your customer, then it's true.

If you are writing code for yourself, then it's totally false.

Reply on news.ycombinator.com