Comment by s3nnyy | Hacker News Reader

Comment by s3nnyy | Hacker News Reader

This is also handy for recruiting.

Stackoverflow includes the famous Joel Spolsky 12-steps-to-better-code list to its job ads (https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...). I think it needs an update after 17-years.

This blog post might be something in that direction. I usually do a similar evaluation when I decide if whether to recruit for a company. (Content marketing: I am programmer and now I source, assess and hire engineers for tech firms and startups in Zurich, Switzerland - see https://www.coderfit.com, and https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-t...)

It is rather challenging as different things carry different weight to different people and there is also the thing that what is good for a big company, or high-growth startup might not make sense for a web agency that will stay below 20 people forever.

Nevertheless, I'd be super happy to brainstorm with like-minded people about what makes a company good from an engineering perspective.

I just got hired on as developer #1 at a 150 year old company that has until me depended entirely on outsourced developers (at great expense and you can imagine what the codebase looks like).

I'm the first developer but not the last so one of the things I'll be doing will be setting the engineering standards going forwards, I might drop you an email.

Slight tangent, but I'll just comment that the business world runs on generally bad software – if they even have "software" and don't just use insanely complex spreadsheets. It's one of those surprising things I've learned doing consulting for the last decade+. At first, I thought it was just the clients I happened to have, but given enough data points, a pattern emerged.

Most software is bad, especially at places that don't consider themselves software companies, e.g., they don't sell a software service/product, they just use software for efficiency.

I don't mean this as a judgement of the developers who wrote it. I've written plenty of software that looks bad in retrospect, from the outside. When you have the context of how decisions were made in the past, more often than not, you find a lot of small decisions that were reasonable in isolation but added together equal a big ball of mess where technical debt was rarely/never paid down, refactoring rarely/never took place, etc.

It's not that hard to convince non-technical business folks of the value of paying down technical debt, but I've found it is hard to convince them to prioritize it. It always gets planned for the future, after whatever super-urgent CEO-driven initiative is currently happening, which is quickly followed by another and another.

So yeah, I can imagine what the codebase looks like but not because of outsourced developers. You could just as easily say, "150 year old company depended entirely on overworked internal developers (you can imagine what the codebase looks like)."

I completely agree except in this case the software is just outright bad.

I found a function yesterday that was 15 lines and reduced it to one, it was a Boolean check but they hadn't just returned that.

Its mostly php and they declare all variables and then immediately overwrite them, I'm not convinced the main programmer had a good grasp of PHP tbh.

In any case its mine now. :)

Yep, there are definitely exceptions to my "generally reasonable in isolation" idea, where the software is just bad, in any context. I've seen 'em. Hell, I've probably written 'em.

Anyway, good luck. I've been in similar situations. It can be overwhelming, but if you have executive buy-in, you have a big opportunity to establish a new direction and effect significant change.

See The Joel Test for 2017: https://news.ycombinator.com/item?id=14052508

Reply on news.ycombinator.com