3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand c…
What I’ve Learned in 45 Years in the Software Industry
121–130 of 371 posts
Re: What I’ve Learned in 45 Years in the Software Industry
#122This sounds amazing. I'm curious...how does salary change? Or does it change? How is all of this handled...
Re: What I’ve Learned in 45 Years in the Software Industry
#123This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…
Expecting a talented software engineer to "upgrade" to become a manager of a development team makes exactly the same amount of sense as expecting a talented accountant to gain a bit more skill and suddenly become a lawyer.
Re: What I’ve Learned in 45 Years in the Software Industry
#124Earlier quoted context omitted.
> My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. I'm growing further and further away from this mentality in hiring because the sad truth is most of those folks who come in with "quirks" lack maturity. To me, quirks…
> not dressing appropriately for an interview What is "dressing appropriately". I wore a suit to my very first interview for a dev position and very nearly didn't get the job because they were worried I wouldn't fit in (luckily I was able to explain that I don't usually wear a suit). The other ones in your list, sure. But I don't think those are what people typically means when they talk about quirks.
I sort of twigged that I was over dressed when on the way to the interview some one stopped me in the street and asked me the way to the "Ivy"
Re: What I’ve Learned in 45 Years in the Software Industry
#125Earlier quoted context omitted.
First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives. Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products. It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regu…
It's similar to the systems administrator dilemma. Do your job well, it looks you are not doing very much, why are we paying you? Everything is on fire, it looks you are not doing your job properly, why are we paying you? I've worked with a few engineers over my career like the person you described and frankly they are worth their weight in gold, been able to bank on their output working reliably and consistently ove…
Installed update X to prevent risk Y
Wrote script to advance process Z on input A
Etc...
Re: What I’ve Learned in 45 Years in the Software Industry
#126This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…
Yes. The challenge is how to measure individual contributors. It’s easy in Sales, which is why salespeople can do very well without being managers. Harder with engineers, whose work is very interconnected.
Re: What I’ve Learned in 45 Years in the Software Industry
#127Re: What I’ve Learned in 45 Years in the Software Industry
#128This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…
Expecting a talented software engineer to "upgrade" to become a manager of a development team makes exactly the same amount of sense as expecting a talented accountant to gain a bit more skill and suddenly become a lawyer.
It’s an art and a science. So I much prefer the comparison with pro athletes who become coaches or actors who become directors.
Re: What I’ve Learned in 45 Years in the Software Industry
#129Earlier quoted context omitted.
First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives. Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products. It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regu…
It's similar to the systems administrator dilemma. Do your job well, it looks you are not doing very much, why are we paying you? Everything is on fire, it looks you are not doing your job properly, why are we paying you? I've worked with a few engineers over my career like the person you described and frankly they are worth their weight in gold, been able to bank on their output working reliably and consistently ove…
I once worked at a place where the development process for the Windows version of their product was GLACIAL because there was no way to run the CI scripts locally or even set up a dev environment that could build the product. People actually edited code in a text editor and then submitted it to github and waited an hour for the CI job to build a virtual Windows instance, run updates, install Visual Studio, Oracle, and all supporting software, run the compile and bail with a syntax error :((((((
So I made a Powershell script to install everything from scratch on a fresh Windows 10 or Windows Server system using Chocolatey. The script took about an hour to run, but once it was done you had a Windows box (or VM) that could build the project in 2 minutes at most, or just run the CI script directly before committing. Suddenly it didn't take weeks to fix bugs in the Windows client, and corrupted installs or DLL hell was one "wipe", "run script", "walk away while it churns for an hour" cycle to a perfect dev environment again.
I was fired 6 months later for "not stepping up enough".
Re: What I’ve Learned in 45 Years in the Software Industry
#130Earlier quoted context omitted.
Do you happen to know of a properly written (publicly available) spec? I'd love to see a good example.
I'm afraid not. The best I can do right now is offer an example outline of what I do. That said, if I'm working with a good project manager my format will differ: I'll focus a lot more on the technical details and leave all organizational aspects out (e.g. timelines, dependencies and impact on other teams, etc). The key principle is that anyone (sales, marketing, support, product, etc) should be able to benefit from…