Live data from Hacker News

What I’ve Learned in 45 Years in the Software Industry

bti360.com

121–130 of 371 posts

Re: What I’ve Learned in 45 Years in the Software Industry

#121

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…

At a previous job, I was the only person to document architecture structure and design choices in a document in each repo I worked on. They turned out to be very helpful for the new employees we took on over my time there. While that's a great plus, the real reason I wrote those was for myself because there is no way in hell I'll remember how to deploy this app to a new EB instance.

Re: What I’ve Learned in 45 Years in the Software Industry

#122
> At EDS, the culture wasn’t like this. People moved in and out of management roles. There was no stigma associated with moving from roles with greater scope, like strategic planner, to roles with more narrow scope, like PM or project-level developer.

This 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

#123

This 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.

Best manager I ever had was a engineer.

Re: What I’ve Learned in 45 Years in the Software Industry

#124

Earlier 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 went to an interview (London UK) for a big name agency suited and booted and was interviewed by some one in a scruffy t shirt that looked like his dog had been sick on it.

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

#125
post #56

Earlier 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…

It just occurred to me a sysadmin log would be very valuable:

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

#126

This 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.

Team mates, usually know who is a good engineer, and who's not - much more accurately than management. When I was in Google, Perf process was based on peers feedback, and it worked well.

Re: What I’ve Learned in 45 Years in the Software Industry

#128

This 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.

That’s a really weird analogy... Writing software (in any reasonably challenging context) is not administrative grunt work with clear and easy definitions of right and wrong.

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

#129
post #56

Earlier 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've been bitten by this.

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

#130
post #23

Earlier 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…

I would also add use version numbering on all docs and properly minute meetings and action points.
Post reply on HN