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

101–110 of 371 posts

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

#101

Post by freedomben »

noir_lord wrote: post #90
duxup wrote: 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…

> Fundamentally it's because impact is harder to measure than perception.

Absolutely. Another nontrivial variable is the tendency for managers/team leads to get the "credit" for successful work, even if they aren't trying to.

I've had managers before that did nothing but impede a high performing team. Luckily we delivered despite this. But it never failed, the manager would get accolades (often very public) for successfully releases, customer feedback, etc, and would end up promoted up. Meanwhile the team kept doing our thing, getting barely-matches-inflation annual increases and more and more micromanagement from the scrum diehards. Didn't take too long for the team to move on to better things. I have a dream of someday reuniting the super team for a sweet startup idea. Not likely to happen but I can dream :-)

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

#102

Post by one2know »

xyzelement wrote: post #22
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…

What you're saying is important for everyone to internalize. I'll spin it like this: Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage. If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure y…

Found the manager. This is just more developer hate drivel. Yes, if you think managers are more valuable, then obviously you are going to say engineering work is "incredibly limited" and manager activities are "orders of magnitude more impactful" Listen, no amount of ass kissing and brown nosing is going to solve actual tech problems.

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

#103

Post by disgruntledphd2 »

marcinzm wrote: post #85
lrossi wrote: post #74

Earlier quoted context omitted.

Do you know why Amazon is focusing so much on the Leadership Principles questions, yet there seem to be so many horror stories from people who work there? I am genuinely curious why they don’t manage to filter out the jerks.

As I see it, the Amazon leadership principles are designed to select for jerks. Specifically jerks who make money. Just look at them. One or two out of fourteen indicate to not be a jerk (Earn Trust, maybe Hire and Develop the Best) while multiple other ones rewards you for being a jerk if you succeed (Disagree and Commit, Bias for Action, Insist on the Highest Standards, Are Right A Lot, Ownership, Deliver Results,…

I think that you may be onto something there. I have noted that when I meet (many) ex-Amazon employees, a lot of them (especially on the business side) are not nice people to work with (backstabbing, destructive political games etc).

It's come to a point where I kinda assume that they are likely to screw me/other people if I don't know otherwise.

(Obviously this is a generalisation, I'm sure there are loads of really nice people at Amazon).

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

#104

Post by macjohnmcc »

cmrdporcupine wrote: post #19

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

I'm happy to lead as long as I also am allowed to work on the code itself from design to actually writing code. I have been doing this full time for 35 years and I would be miserable had I switch to a pure management role at any point including now. Meetings kill motivation for me.

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

#105

Post by tristor »

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.

> Do you happen to know of a properly written (publicly available) spec? I'd love to see a good example.

As somebody that has written hundreds of specs and PRDs over the years, I think one of the counter-intuitive things about doing it well is that there is no such thing as a "properly written spec". Or more accurately, "properly written" isn't a single path. You can't really templatize this in a generic way.

Instead, I'd offer the following basic advice which will help to build good specs:

1. Create an outline first, enumerate the list of stakeholders and the sections/topics that those stakeholders are most interested in addressing. Use this outline as the basis for filling in the details.

2. Don't write more than you have to. Rather than being overly verbose, establish the context of what/why/when at the top of the document in a summary, and then focus only on the most relevant conclusory details in each section after. The more shared domain knowledge the stakeholders have, the less you have to write.

3. A good spec results in a finished product/feature/widget. Be clear about what you know, what you don't know, and what you believe. Leave room for things to be discovered during implementation. Be concise.

Basically, don't write more than is necessary to actually achieve what the output of the spec is trying to achieve given the team/organizational context that the spec is going to be used in. Be as concise as possible, eschewing verbosity when possible because shared knowledge already exists. For this reason, "properly written specs" are very team/organization/project/product/person dependent. There's no universal format that works.

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

#106

Post by kingnothing »

lrossi wrote: post #49
marcus_holmes wrote: post #43

Earlier quoted context omitted.

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?

Depends on what you mean by "people problems".

Perhaps read some books on negotiation if you have issues getting others to see your point of view.

Nervous about speaking in front of a group? Try Toastmasters once the world opens back up, or hire a coach.

Books are a good first resource once you identify the areas in which you want to grow.

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

#107

Post by nicoburns »

peterangular wrote: post #61
nicoburns wrote: post #44

Earlier quoted context omitted.

> 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 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 Yeah - I hate this. I had people at my last position give candidates negative points because they wore a suit and I went $%&#ing ape. In positions that I've held in the past it's been the appropriate action to wear a suit due to heavily corporate environments, and I see it as 11…

> The action of wearing a suit (or tie for that matter) to an interview should never be seen as a "cultural fit" problem

I would agree and would go as far to say that dress in general should never be a hiring criteria for a non-customer facing position. Unless there are hygiene issues or they are wearing something actively offensive.

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

#108

Post by 8iu9dua02 »

davidhyde wrote: post #60

> “ When you know something it is almost impossible to imagine what it is like not to know that thing. This is the curse of knowledge, and it is the root of countless misunderstandings and inefficiencies.” A few months ago I came across an interesting actively developed project in embedded rust which was very technical. Full of acronyms and concepts that I was not familiar with. It took quite some time to get up to s…

You did nothing wrong. My team produces roughly equal amounts of documentation and finished product code or other artifacts for bank consulting engagements. Knowledge within the customer's organization is usually scattered all over the place and very few people know how it all fits together due to employee turnover and attrition. The actual customer (VP) is grateful when we are able to piece together what is really happening and the high level state of the system while we streamline their systems.

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

#109

Post by castlecrasher2 »

trentnix wrote: post #58

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…

>Assume the next person to maintain your code won’t be as smart as you.

It's especially easy to assume this because I've often gone back to code I made a year or even months ago and barely understand it.

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

#110

Post by macintux »

one2know wrote: post #102
xyzelement wrote: post #22

Earlier quoted context omitted.

What you're saying is important for everyone to internalize. I'll spin it like this: Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage. If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure y…

Found the manager. This is just more developer hate drivel. Yes, if you think managers are more valuable, then obviously you are going to say engineering work is "incredibly limited" and manager activities are "orders of magnitude more impactful" Listen, no amount of ass kissing and brown nosing is going to solve actual tech problems.

This tone is unwelcome on HN, which is probably why your previous comments have often been downvoted and flagged.
Post reply on HN