Software development topics I've changed my mind on after 6 years in industry
chriskiehl.com
chriskiehl.com
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.
Any time you find yourself saying "It's not the field that's fundamentally broken, it's that (almost) every individual in it just happens to suck (at it)," you need to take a step back and realize that that's the same problem.
If you have to be exceptionally skilled at something to do it in a way that's net positive, and that field doesn't reasonable filter for the exceptionally competent, then the field is setting individuals up for failure, and needs to be restructured.
And if most people in the role suck at it, you by definition have to be exceptionally skilled to succeed. Even if from the outside it looks like the people just tend to suck and the field is easy.
In the case of project management, what you have is horrible hiring practices that favor extreme credentialism (PMOC, etc) rather than a proven track record of results. Businesses seem think that anyone with a cert is going to be effective, but in my view, these certifications are mostly worthless in terms of actual skills gained.
Another thing is, what should even change? No one knows. This isn't an unknown phenomenon, there just isn't anything better at this current moment. It's very easy to point at things and say they should change, another thing entirely to propose a solution. To me, I would put more technical requirements on PM's rather than these dumb PM certs, as the better PM's I've worked with always seem to have a much deeper understanding of technical nuance than their shittier peers.
This applies to business analysts, scrum/agile people, communications people, and other non-technical project staff, too.
I've observed an arms race at play in my department. Our team used to be 4-to-1 developers to business people. But we've increasingly needed to hire more business people just to defend ourselves against political scheming.
But the question is why? I spent a decade of my career in civil engineering, and on the whole every project manager I dealt with there was both at least OK at their job and important to the success of the project. None were useless. If other technical fields can reliably produce competent project manager, why can't software?
It can, but remember that we lost the competency to Agile, which is centred around eliminating managers in favour of self-organizing teams. For a time we didn't think we needed managers at all.
As we as an industry are coming to reject self-organization and now returning back to more formalized management again you might find some old timers from way back in the day who still remember how to manage, but if you watch any new manager coming onto the scene you will notice that they will reach for tools that were designed for operations without managers – because that's all they've ever known – introducing an interesting impedance mismatch.
It will no doubt correct some day, but these kinds of things tend to happen at a glacial pace. It could take decades for managers to discover/rediscover tools that are actually suitable for management, rather than something meant for self-organizing teams. As before, newer managers don't know anything else, so the impedance mismatch isn't even immediately recognizable. The default assumption is that this is just how it is done.
True, but project managers are even worse! (There are always exceptions)
> 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.
This also ties in to what I call the "linter fallacy"; which goes something like:
"This code passes 56 linters"
"Therefore, it's good code"
And the related:
"Our code is a mess"
"I spent a week adding 56 linters and rewriting it all to pass"
"Therefore, now our code is good"
What really matters is "can I read this code naturally?" And if the answer to that is "yes" then it may be good code. Obsessing over whether it should be written with some small differences that don't really matter is just not useful for anyone.
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.
False. This is not Tinder: if you don't want to move forward, an email stating as much is super cheap.
Anyway it's much the same, since most competent HR software can autosend a 'no thanks' email when the system bulk-rejects applications.
Whether or not a person is involved, it's so little effort to send that close-of-conversation email that there's no reason not to. Meanwhile, the point of Tinder is that people choose when and how to engage. They're not the same.
There may be essentially no effort to say that you are no longer interested, but at the same time if you are no longer interested, who cares?
The stakes are also higher. Yes, love is more important than money, but having a job at all is definitely lower on Maslow's hierarchy than finding a romantic partnership.
Perhaps, but their self or their institution don't want you, so why would they be concerned with what you think of them?
In the olden days where you only had the choice of the 20 people you could realistically get in touch with by horse, there was always an inkling in the back your mind that maybe you'll get desperate in the future, so there would be a lot of fear around completely destroying ties. But now that there are 8 billion people at your immediate disposal, there is no reason to cling to something you clearly don't want.
In fact, if their actions give you a sour taste, that's ideal! It will save them from thinking you are a good idea later when they have a desperate moment. If their niceties leaves you still willing to engage even after they realized you're not a good option, that's not a good place for anyone.
In the United States of America, you call the company. In Germany, employees get a certificate.
If you get 100 applications for an opening, your HR tool can automatically send emails to declined candidates. You do track which ones you’ve rejected in the past and which ones you go forward with, right?
And on and on. It’s not hard.
> 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.
I think the real takeaway here is that code quality doesn't really matter. The most horribly written code is still quite fine to work with if well documented.
/* BadImpl.java */
if (theFile.exists()) {
doTheAwesome(theFile);
}
// uh, and else ... what?
/* BadImplTest.java */
@Test
public void looksGoodTestCoverage() {
theFile.create();
instance.runIt();
println("hurray, 100% coverage");
}
if (theFile.exists()) {
...
} else {
}Previously:
... 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
Or at least, that's how it should be. But half the people tell long shaggy dog stories because they fear "I worked on feature X, it's going well" or some such is too short or basic, but it's not. Or they turn into long protracted debug sessions that's only really of interest to two people but 7 others are watching. That should be done after the standup.
It's really just intended to 1) give everyone a basic idea of what people are working on, and 2) a moment to check in and ask for help, and/or offer help.
But when was the last time you saw a team without managers? When you have managers, the whole reason for their existence is to take that kind of management work off the plate of developers, so that the developers can focus on what's important.
If you are having standups and managers, you need to seriously consider replacing the managers because they have straight up failed to do their job.
What's important are blockers like inability to implement something, missing permissions, awaiting external communication, freshly detected requirements that need a decision, absences etc pp
Oh, in that case one should definitely wait 23 hours to bring that to anyone's attention, and for sure an (allegedly) 15 minute meeting is a great place to get requirements
> absences
Uh-huh, go ahead and include births and puppy adoptions, too; I can see that you and the Certified Scrum Master™ have obviously attended the same workshops on Team Health
If one wants a status report, fine, have one periodically. But don't vaporize 30 minutes a day times 7 people just to go around the room talking. What a 1950s concept holy shit
I have never in my life met a professional who sits on their hands for 23 hours waiting to say "uh, I have a blocker, but wanted to save it for this magic 15 minutes to ask for help." Yes, fine, n00bs do that, and that's what TFA was saying that interns need supervision, who knew.
I will if there is a regularly scheduled meeting to discuss such matters. If the company is fine with you taking the day off, take it!
And yeah, I also can't agree more with your assessment about status reports being this relic from the past. What is this? The military? "SITREP. NOW!" Such a waste of breath, time, human life.
I feel we should separate these two things into async slack status reports and them regularly maybe bi weekly 30 minute team building meetings where no work is being talked about.
How did we get to the point where we determined that the only way to get anything out of developers was to setup a meeting to force it out? Telling them they must provide a status update on Slack instead is ultimately just a different cartoon character on the same basic bandaid – What is the actual problem here?
But I mean with respect to managers. The collaboration with them used to be exciting. What changed?
The daily standup comes from XP, which has no real concept of project managers or team leaders. Under XP, everyone is considered to be the project manager and team leader, so to speak. Thus, that isn't technically possible in the strictest sense.
If you have a "standup" in name only for the benefit of distinct project managers and/or team leaders, then I suppose you can just not show up. If that raises alarm in the organization, you're the newbie and just don't realize it.