21–30 of 159 posts
Definition of a professional: "engaged in a specified activity as one's main paid occupation rather than as a pastime". I wouldn't call fixing azure pipelines without any professional debugging tools a pastime activity.
Although I've met unprofessional people at work. Being a professional doesn't mean you're an expert.
One of the problems I faced is that the university didn't teach TDD, I couldn't find any books about TDD and every single programming course didn't even have a section about TDD. It's like this was some kind of secret knowledge that only few had. I was only able to learn TDD when I joined one corporation and it was like a new world to me. I tried to learn as much as I could and then carry that to next jobs. It's bett…
Though I am not very keen on the underlying reasons the author gives. Seem to be anecdotal and not cover a host of other situations the solution could cover. I think there can be many other reasons. Cultural for one.
In the example of the professional team they may still be beholden to write cheap code because of certain business decisions, despite tests and the fanciest of ci builds. Additionally ‘amateur’ teams could still produce high functioning websites if there goals were shifted toward leaning and measurements taken against customer satisfaction and reduction of bugs over time.
Because long-term maintenance isn't the concern. Most devs switch jobs in 2-5 years (or at least that's the common advice given). So the incentive is to play musical chairs, and hope that you've moved on by the time the music stops. Software has also been such a new field that it was the startup that moved fast and broke things that got the prize rather than the slow but stable company. I think this is changing (lowe…
Further, management notices and rewards the developer who is chewing through tickets, especially when those tickets are visible, user-facing features. If those developers are sloppy (and they tend to be), the bugs, readability issues, etc don’t get traced back to them and the rest of the team gets no glory for cleaning up after them and actually productionizing the prototype-grade shit they deploy to production.
I chewed through tickets and regularly had an above average point score every sprint, even as a brand new junior developer. I sometimes had the highest on a team where everyone else had 5+ years of experience, which should have raised red flags. Heaps of praise though.
And I was doing it by taking the most direct path to it working without really knowing the potential consequences (which I didn't understand at the time).
The guy who wanted to do refactoring didn't get his contract renewed as that was not productive work.
This explains a lot of my interactions with my peers. Some groups of developers need hand holding, guidance, feedback, and correction. Continuously. The other group just gets stuff done and get normal feedback I”d expect from my own work. When one of the first group complains about code, I try to explain why it’s written that way. When the second group complains, I ask what we can do to fix it. Amateur vs pro may act…
An ask of anyone reading this article: Please don’t let yourself become a smug or cynical programmer. Too many programmers read articles like this and assume that they are the 20% of good programmers while everyone who disagrees with them is the 80% of amateur developers: > I have worked in software development for 20 years, worked on many projects with many software developers. I estimate 80 percent of software deve…
I mean, he's not wrong.. but I always get suspicious if somebody is making up percentages. You know 90% of percentages are made up? (Yes I just made that up)
This line is packaged to sound really insightful, but is it?
The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things.
If I write no software today, I've also written no new bugs. But have I made any progress toward achieving the mission?
Feels like this person is very frustrated with novice engineers writing buggy code and has assumed a gatekeeper role to protect the integrity of the codebases in which he holds responsibility. It may be a necessary role at his organization, but I just don't agree with the cynical and depressing message.
500 error?