I've been thinking a lot lately about 1.) the avalanche of layoffs happening across the tech industry, 2.) the current push to drive remote workers...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Thank you for writing such a great article.
Programming is so much more than just typing on the keyboard! And it pains me that so many managers overlook this, and play it off like it is simply just typing mindlessly. You try to explain why your estimates are xyz and halfway through you realize they probably do not understand anyway. Or when it comes to stand-up meetings, it seems you "barely" achieve anything because you just added something "small" like a button.
One of the best lines I heard was "It is just a copy and paste, why does it need to take so long?"
Sounds like a lot of these problems derive from tasks that are secretly large in scope. How to approach these problems depends, but from my experience, I've had better luck expecting the task to take ages rather than expecting quick and easy. The biggest time suck for me is hierarchical relationships. Anytime there is parent/child relationship I expect the complexity to go up by at least a factor of three.
I've also learned over the years, if you are not asking about how the data is related you're going to get burned. Clients will request something like a little checkbox or clone button. These features sound simple, but in reality it will easily take weeks because you have to restructure all the data, and data driven elements. The smallest features are often times the most complex and tedious.
Agreed on all points!
I think this could be generalized to most groups within IT not just software dev. This is especially true in businesses where their core product is not software. In these environments, IT is just a cost center that may be seen as not revenue generating thus continually asking IT to "do more with less", then they get upset when things break or schedules slip.
Very well said. Having been a software company CTO for 20 years, I had a recent gig that was trying to become a software company but couldn't make that transition easily. I was a fish out of water there and I don't think it worked out for anyone.
I totally agree with you. In most of the places I've worked, IT is regarded as a Cost Center and I've had to rely mostly on FOSS and open-source tools to get the job done. Plus it infuriates management to see my team 'lounging' around and 'having nothing to do'. It was so bad at one place that my Line Manager advised me to master the art of "eye-service" (pretending to be busy whenever top execs are around) if I wanted to last long.
Agreed. I currently work in an institution that relies heavily on web applications created and managed by the software department and yet we are often overlooked. They would want new features and bug fixes to be completed with insanely small timelines (that are hard to extend). The only thing created under those conditions is bad software.
That's very true, and the other side of the coin is true.
One of the things that have been proven to make employees happy is to have a boss that understands your job.
Indeed, two of my favorite job experiences were in a company where the CEO was a former (cool) developer.
This is a great post and very much reflects my own experience as well. As a junior developer 10 years ago, I dealt with a project manager who thought SD was pretty much typing. If we were not typing on our keyboard, he would get upset that we were not working! Once he told me that if people are not stressed at their job, they are not working! Imagine that. My best times as a developer have been with managers who are part of the development team and have to code daily. SD is not a normal job and is definitely not for everyone.
I forget if I have mentioned this in you comments before, but I think the best metaphor for software that biz might understand is that software development is management. We build a shadow organization in parallel with the human organization. Junior engineers are essentially low level management. CTO is the shadow CEO. The workers we manage are the computers. We write detailed documentation for the computers on how to do their jobs (code).
This explains why a good dev team will generate and monitor important metrics.
I have yet to figure out what this metaphor means for engineering managers though.
As a manager i'm ashamed to say that some of this is at least true for me. I often find myself in too many meetings to write code or debug something fully, and my sparse time means I can't review every single PR each day that makes it to production.
In my defense, I do try to review all PRs, even if they are merged, to get an understanding of what is happening on the codebase.
I think they key advice I might have is to duck out of meetings you don't need to be in. Having taken this advice myself, it gives back the time for the meeting, as well as the time around the meeting where you might be attempting to wrap up a task or perform meeting related actions.
Totally agree!
I love this article!
I quit software engineering for several reasons (I won't deny that I was part of the problem).
But, one thing that I couldn't stand was that I was expected to deliver code every single day.
Not everyone can bang out code every day.
There are internal and external factors that can impact a developer's productivity.
And I couldn't explain my manager how certain non-coding tasks ("grunt work", as you describe in the article) can take hours, if not all your day to accomplish.
And even if you do, there's always that chance they could think that "that should be easy".
Teamwork is also another one. Managers want developers to work as a team, but then it feels like a punishment when a developer takes the time of another developer, impacting "productivity".
In my previous companies, I got to the point where I didn't want to ask for help anymore, because I was taking time away from seniors who were "too important".
This reminds me of an article by Joel Spolsky (on "Joel on Software", I think it was an article about the need for functional specification) about two programmers: one who is coding and seen coding - but produces shitty code, and one who thinks first and creates great code.
This article is very insightful. But also a bit depressing. I can't wait for the good news in part two.
Hehehe, yes. There are definitely some depressing aspects to it. I don't have any "silver bullets" to offer. But I do plan to provide a few actionable ideas. Stay tuned...
Great article, drenched in truth.
Thank you.
Very insightful post, thank you.
AGI will replace developers. By definition AGI is the same as human mind. An offshore is a limited resource. If the industry grows faster, then you will hire in both on- and off-. An AGI is just piece of data which you can instantly and infinitely copy. The limiting factor is the compute. And compute means money. If a couple of GPU/TPUs would be enough to run an AGI, then human developers have no chances. And AGIs could have a physical body. The shift will be so big, that not many people could even closely imagine were it will lead us.
So, it's not very productive to be afraid to loose your software engineering job because of AI. It may not happen at all or it may be the least of the problems.