Comment by ilovecaching | Hacker News Reader

Comment by ilovecaching | Hacker News Reader

I have a very bleak outlook on coding after moving to the bay. The companies that win and get big do not put stock in writing good code. They want to move fast so they can beat people in the market. So you end up valuing people who can do whatever it takes to scale and keep things working while ignoring your tech debt until you’re so big you can just hire 20k engineers to clean the mess up over the next two decades.

With this approach young engineers learn that clean code and everything people like Martin Fowler have been saying isn’t going to get them promoted. So people learn bad practices and we all get collectively worse at coding.

I’ve spent so much energy trying to get people to care about code quality and qualitative improvements, but at the end of the day the people who got these companies were they are can just say there method works and there’s no proof it would have gone better with better code or that they would have survived at all.

Reminds me of the jwz quote:

"I know it’s kind of a cliché but it comes back to worse is better. If you spend the time to build the perfect framework that’s going to do what you want and that’s going to carry you from release 1.0 through release 5.0 and everything’s going to be great; well guess what: release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you’re out of the game. You never shipped your 1.0 because someone else ate your lunch."

You're commenting about this on Hacker News, a site that--from a technical perspective--does almost everything "wrong", or using methods that have been obsolete for 10+ years. It uses tables for layout. It does "AJAX" by creating an <img> tag and setting the src= as the url to request. It has an awful url structure (e.g. item?id=20996837). And on and on, I could list so much more.

But you (and I, and thousands of others) still use the site and probably didn't even notice or care about any of that. This is one of the largest, most heavily concentrated technical audiences on the internet, and even though those are the exact people you think would be most discerning about it, obviously nobody truly cares about how much isn't being done "properly". People will argue all day in the comments here about the right way to do things, but since they're here they clearly don't think it's important when deciding what they use themselves.

It's the same for everyone else, with every other site and product. As long as it works, the reality is that almost nobody cares how much of a mess anything is internally.

You've picked a poor example to prove your point because web development collectively jumped the shark and websites using technology from around 2006 are the most reliable and easy to use.

Back then usability, graceful degradation and progressive enhancement were appreciated by developers. Nowadays we have the complexity of Enterprise Java except with less reliability and in JS. And ads and tracking and virality everywhere.

The best code is what gets the job done, and on schedule. Customers don't care what design patterns you are implementing or what your unit test coverage is. I don't think of it as a "bleak outlook", just reality. It was true 15 years ago and is true today, and IMO overall coding standards are only getting better, not worse.

Does getting the job done include being able to improve the product later?

Code is means to an end, not a goal in itself. A "bad practice" is relative to the purpose and the constraints.

Fowler writes for enterprises which have large, long-lived systems.

There is an optimization that needs to be done between manageable code and deliverables. If your code is poorly structured it may be very difficult to expand or iterate upon. This is not ideal, and will slow down your goals.

However you could spend forever rewriting and refactoring. What is the value in that?

Excellent point. Companies need to make money to keep the doors open. There is no money made in fixing something that isn't broke on the off chance you might end up needing to utilize that code later. Tech debt should be addressed when necessary, not just on a whim because someone is uncomfortable with less-than-optimal code. Refactored code requires testing just like any code update, sometimes more depending on how significant the change is.

Reply on news.ycombinator.com