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

41–50 of 371 posts

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

#41

Post by mr-wendel »

yarinr wrote: post #23
mr-wendel wrote: post #16

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…

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 reading it and find it intuitive to see where you're getting into the technical details and skip ahead to the next major point.

1. Overview

A paragraph of two explaining the what and why of the project. Maybe some links to other related key documentation. Don't put anything technical here.

2. Change Log

Bullet-point list of dates and major changes. Think of it like a git commit history.

3. Scope

What systems are affected? Are there phases to the project to be called out? If its principally one system/repo/etc in question, what major components are changing?

4. Requirements/Tasks (the main body)

Use a numbered list and aggressively refactor as you go so high-level items rise to the "left" and all related details are broken out as sub-lists. You can loosely think of it as something like "[section] > [epic] > [task], [task], [task]". Prioritize the list based on dependencies so you're always referring back to already-mentioned requirements instead of yet-to-be defined things.

5. Supporting Docs

Put long-form examples, scenarios, diagrams, etc in their own section. Some people will only care about these, especially if they provide integration examples.

6. Concerns and Questions

Ideally by the time a first draft is done this section no longer exists, but usually you'll find that you need to do research or get feedback from others to finalize the whole thing.

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

#42

Post by rileymat2 »

karmakaze wrote: post #33
Accujack wrote: post #32

Earlier quoted context omitted.

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 might be closer to a pro athlete retiring from playing and going into coaching, but not so many would be good in that role.

This is interesting I did a bit of Googling, I guess it varies by sport quite a bit. https://www.post-gazette.com/sports/around-the-league-nfl/20...

Some sports, most coaches came from players, but the NFL notably does not.

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

#43

Post by marcus_holmes »

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 entered the industry with no degree, having taught myself to code. After approx 15 years as a developer, I decided to get a degree, because it was becoming a problem (Australia is very sensitive to qualifications). I decided to get an MBA because all the hard problems I'd met were people and/or business problems.

The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then the trade-offs are generally well-known. It's rare to run into a problem that requires complex technical knowledge, and in those cases it's fine to hire a consultant to help.

But the people problems are hard. Getting clued-up on these is important.

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

#44

Post by nicoburns »

peterangular wrote: post #35
motogpjimbo wrote: post #26

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. Maybe it's different when you interview at a FAANG company though? I imagine FAANG recruitment is a merciless sausage machine.

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

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

#45

Post by airstrike »

marcus_holmes wrote: post #43
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 entered the industry with no degree, having taught myself to code. After approx 15 years as a developer, I decided to get a degree, because it was becoming a problem (Australia is very sensitive to qualifications). I decided to get an MBA because all the hard problems I'd met were people and/or business problems. The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then…

Wow. This must be the very first pro-MBA comment in the history of HN. Feels refreshing!

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

#46

Post by dboreham »

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…

"Psychology is eating the world"

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

#47

Post by yarinr »

mr-wendel wrote: post #41
yarinr wrote: 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…

Thank you! this is helpful

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

#48

Post by codingdave »

mewpmewp2 wrote: post #36
__jem wrote: post #15

Earlier quoted context omitted.

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.

In which case are you not going to lock in building something like that? Even if you opt to go framework-less you are now locked in to whatever you are building.

This is somewhat true, but that is why separation of concerns is a best practice. Maybe you do have one piece of the stack "locked in" to Rails, but the rest of the stack can stay in place if you want to move from Rails to a different framework.

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

#49

Post by lrossi »

marcus_holmes wrote: post #43
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 entered the industry with no degree, having taught myself to code. After approx 15 years as a developer, I decided to get a degree, because it was becoming a problem (Australia is very sensitive to qualifications). I decided to get an MBA because all the hard problems I'd met were people and/or business problems. The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then…

What kind of resources would you suggest to someone who wants to get better at handling people problems?

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

#50

Post by bradstewart »

rileymat2 wrote: post #42
karmakaze wrote: post #33

Earlier quoted context omitted.

It might be closer to a pro athlete retiring from playing and going into coaching, but not so many would be good in that role.

This is interesting I did a bit of Googling, I guess it varies by sport quite a bit. https://www.post-gazette.com/sports/around-the-league-nfl/20... Some sports, most coaches came from players, but the NFL notably does not.

I wonder if team size has anything to do with that. Football teams are much larger than those in other sports.
Post reply on HN