Software development topics I've changed my mind on after 6 years in industry

This is more a statement on how many bad project managers there are rather than on the role itself being useless. I've worked as an IC with a lot of PM's over the course of my career - I can definitely bring to mind a few PM's that left a huge impression on the project I was working on. I can think of many more that were completely worthless. I think the latter group makes developers think the role itself is useless, which I could not disagree more with. Developers are absolutely terrible at balancing business and customer priorities with technical ones, and the worst part is, many of them believe they aren't bad at that.

> People who stress over code style, linting rules, or other minutia are insane weirdos

I feel like programmatically enforced linting is like keeping a shared house clean. Suppose you live in a house with roommates. You wipe off the counters, you clean up after yourself, you put dishes in the dishwasher, so that the house is tidy and pleasant. If there's a lint or style rule that requires judgment and is hard to enforce programmatically, perhaps better left as an occasional PR comment.

Programatically enforced linting also has the benefit of removing degrees of freedom that aren't very important and don't merit getting bogged down about.

If you're relying on a daily standup to keep the newbies on track, then something is deeply broken with your management and people development structure. They should be continually coached one-on-one, rather than left to fend for themselves only then to pipe up once per day. A little time investment by both the noob and someone more seasoned really, genuinely helps them to get up to speed. It's something that will pay itself back many times over in the future.

I've experienced both when I stepped in as a greenhorn, I leveled up so much faster when I had the ability to pepper questions throughout the day to someone more seasoned. And I remember feeling discouraged and listless in a culture where you don't interrupt the senior people, wait for the standup, regurgitate your problems, speak the scrum prayer every morning.

Does it cost something in terms of efficiency, or vElOCiTy? Sure, but like I said above, the returns on investment compound when you really care about developing people, and not being a slave to the scrum process.

Stressing over these things is certainly a Sisyphean task.

However, investing in automating and standardizing the application of these things every time a new repo is created eliminates an entire class of problems and saves you all sorts of trouble down the road.

I resonate with this greatly. I'm in the middle of applying for jobs, and I try to put myself into the recruiter's shoes. At the end of the day, I don't blame recruiters for the calls they make (e.g. ghosting, denying for $REASON).

When you are supposed to interview a potential software dev, how are you going to differentiate the people you should invest into from the ChatGPT extension? How do you know whether the person actually worked at $FAANG_COMPANY for 3 years? Don't forget the other 78 people that also applied for the job.

> Software architecture matters probably more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.

> Pencil and paper are the best programming tools and vastly under used.

> Code coverage has absolutely nothing to do with code quality.

> Micro-services require justification.

It is quite indicative of documentation quality, though, which is most important as a codebase ages. You may know how it works now without documentation, but future developers (which may include you) are going to want more information to know what kind of expectations are found around the code.

I'm going to disagree respectfully here. I don't think hard-and-fast rules on code coverage are useful (e.g. must achieve 90% coverage before merging), but just having code coverage run automatically and its results displayed is useful. When I add an "if" check and one of the branches isn't covered for example, I start to think what if some junior engineer didn't understand the reason behind this "if" check and decided to delete this check altogether? If no unit tests fail after deleting this check, that junior engineer might not have enough context to judge whether this check is needed in production.

Previously:

2022 https://news.ycombinator.com/item?id=32162716

2021 https://news.ycombinator.com/item?id=25887373

... and thus should include only project managers and/or team leaders and leave the rest of the professionals to do work and provide status updates via the bug tracker