Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bti360.com

Post reply on HN
Print view View original

11–20 of 371 posts

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

#11

Post by mistrial9 »

lrossi wrote: post #6

Something that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest. This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, d…

professional interview sign seen at the "interview desk" for work placement at an expensive school for digital creatives: "sit up straight; look the interviewer in the eye; wear presentable clothing; answer the questions asked of you" .. I believe the sign was there because that was not occuring in many cases !

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

#12

Post by marcinzm »

supernova87a wrote: post #7

One of the tenets though, "6. Be Honest and Acknowledge When You Don’t Fit the Role" only is fair to the person if the team/company also follows that advice. If a team or company does not value, or cannot tell, or does not act if someone is incompetent and unfit for a role, then this advice penalizes those who are honest, and rewards those who are good at faking competence. You need to have a structure of integrity w…

I don't see how your statement disagrees with what he said. He's talking about self-acknowledgement which has nothing directly to do with the organization. For example, if the organization values fake competence and you don't then you need to self-acknowledge that and either start faking it, change the organization or find a new job.

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

#13

Post by eloff »

SPBS wrote: post #8

> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now i…

It is no? It's not easy to rewrite into something else if you need to. With rails the biggest reason you might need to do that is the abysmal performance. You need twenty servers to do the work you could have done with one.

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

#14

Post by stroz »

lrossi wrote: post #6

Something that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest. This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, d…

I couldn't agree more, that said, I believe the difficulty for new hires in software engineering typically comes from the relentless focus on coding interviews.

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

#15

Post by __jem »

SPBS wrote: post #8

> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now i…

Is it not? Even if it's open source, I would view monolith frameworks as a form of ecosystem lock-in. We use Spring at work and I would certainly describe us as suffering from "lock-in" to the Spring ecosystem.

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

#16

Post by mr-wendel »

Stuff I'd add that I think is crucial, and all related to one topic: good writing!

1. Learn to write specs

Call it an RFC, call it a PRD, call it whatever. Writing out a plan for any project taking around a week or more is always worth it. Use it to establish scope and priorities. Keep a "Questions" section that you whittle away at as you seek out feedback. Make the body a hierarchy of design tasks and implementation ideas. Track revision history and keep it up-to-date.

You now have a great way to get sign-off from peers + management, an execution plan, a task breakdown for ticket management and historical documentation on what happened and why.

2. Be terse

Is that email looking a little long? Write a "TL;DR:" section at the top and then see what you can delete. If it's nothing, leave the "TL;DR:". Otherwise you may find you've included a lot of intermediate thinking and people only need to know the conclusions.

3. When learning something new, keep a dedicated list of "this looks like magic!" items

Use your "down time" to research items on this list instead of refreshing your favorite news aggregator. Ask your peers and mentors about them. Notice when tangental issues come up and spend a few extra minutes seeing how they're related and how that might yield some easier answers.

4. When you want to ask for help... defer clicking "send"

Whether its an IM or email, write it up on the side first. Start with your question and follow-up with what you've already done to walk through finding the answer to save the person the effort of starting from step one or pointing out the obvious thing you overlooked. Often this will lead you to answering your own question. If not, still wait 15-30 minutes (if you can) before sending it and work on something else. In that time you're likely to think of something you overlooked and avoid interrupting anyone.

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

#19

Post by cmrdporcupine »

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. For one, organizational incompetence when people who were valuable contributors where they were are elevated up into roles where they no longer can apply those skills as effectively (i.e. technical team lead to management or architect) leaving a vacuum below. A form of the Peter Principle I guess, except the individual may have competence in their new role but not be happy, or make the team itself less successful.

And most importantly, as he touches on: being asked to 'level up' and told that this is your mission can lead to an unpleasurable career. Either when you do get that promo and then find that you don't enjoy the new responsibilities (but become trapped by the position / upgraded compensation etc.) or when you don't get the promo (or don't try) and find that your value in the eyes of yourself and others seems less.

And finally, I think this type of thing can really take hold in places with a highly academic background / focus / origin (like Google, etc.) as it mimics in many ways the grade / peer review achievement structure of academia. And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.

Smaller companies looking to grow/formalize should exercise caution when looking at the rating/performance/promo process @ FAANGs / MS as a model for their own.

(I'm at 20-25ish years in the industry, but really feel junior in so many ways when I read the words of veterans like this.)

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

#20

Post by JMTQp8lwXL »

lrossi wrote: post #6

Something that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest. This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, d…

Both, to some degree, matter. If your team makes poor technical decisions, that could spill over to eroding team trust. Your success is generally tied to how your team performs in aggregate. If your peers mess up, that could impact you professionally as your team's overall standing within your organization declines.
Post reply on HN