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

291–300 of 371 posts

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

#291

Post by AgentOrange1234 »

that_guy_iain wrote: post #186
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…

> 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 you code the right stuff. This seems to miss the point of teams. Everyone should have a role if you hire someone as a software engineer and they spend all their time doing devops becaus…

I can appreciate how this kind of specialization helps a team to scale. At the same time, what I like least about my current job is how structured my role is. ‘Draw within the lines’ is constraining and can push creative folks away.

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

#293

Post by rramadass »

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.

From personal experience, i can suggest;

* RFCs on IPSec.

* ITU Recommendation on H.323 Protocol for Packet Based Multimedia Systems.

* The NIST documentations on FIPS and the various Crypto algorithms.

The first two are an "umbrella" of protocols and thus the specifications go from overview to extremely detailed in a very nice step-by-step manner. The third one shows you how to specify detailed and complicated algorithms.

Writing good Specifications is extremely demanding! But this is the only way to really understand the Domain.

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

#294

Post by 35_candelas »

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…

Goldberg is talking about a longer term view and I think in general, after working for more time your job becomes more about interactions than the "knowledge" you have.

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

#295

Post by grogenaut »

fairity wrote: post #288
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…

> The more of these things you do, you become orders of magnitude more impactful than a pure coder. Your job satisfaction/pay are also a function of how unique your skillset is. With this in mind, increasing your impact (through soft skills) is just one of two ways to increase pay - the other way is to do something that not many others can do. For many people, doing something unique is far more satisfying than dealin…

I will point out that a lot of engineers are bad communicators, and those that are not often change roles. So communication is a unique skillset. As is understanding the business.

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

#296

Post by thyrsus »

ddingus wrote: post #125
noir_lord wrote: post #90

Earlier quoted context omitted.

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

The entries in our ansible git repository are supposed to be that log.

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

#297

Post by bluefirebrand »

barnacled wrote: post #228

Some cynical lessons from 15 years in: 1. Politics is everything - how you are perceived is politics, whether you get assigned the projects you want is politics, career progression whether technical or managerial is entirely politics. You will be told various nonsenses about 'flat structures' and 'meritocracy' throughout your career but it's bollocks. Play the game badly and the flat structure is your career. 2. Most…

> 6. Sideways shifts reset your career to zero - there is no such thing as treating development experience as fungable. You are only as good as your years in this particular slice of the industry and more often than not you are only as good as your years in this particular company.

This one has burned me a bunch of times in my career already and I'm not quite a decade in. I really want to find a corner of the industry I can focus on and gain momentum in my career but it's been challenging to do that.

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

#298

Post by 8note »

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…

Wearing dressy attire from any culture shouldn't get you. Singling out suits is a bit white sulremacist-y

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

#299

Post by gen220 »

dodobirdlord wrote: post #287
gen220 wrote: post #233

Earlier quoted context omitted.

> initiatives for standardization have almost dropped to zero compared to the 1990s and 2000s I think OSS adoption explains this. Standards were all about advocating for common interfaces, even if the implementations were proprietary. Proprietary software was more a thing in the 90s and 00s. Nowadays, common practice is to use open implementations , not just open interfaces. Nowadays, we only see widespread initiativ…

Before the triumph of OSS standardization required multiple parties to come to agreement and then each produce their own implementation, so implementers had an incentive to fight for their own objectives so that they didn't get backed into a corner of having to do unprofitable work. Lots of bickering about was was and wasn't worth including. To navigate this environment requires committees and formal standards docume…

Adding on to your point, the phrase “designed by committee” carries a strong negative connotations for a reason.

People may have some gripes with the implementation of some subsystems, but they are free to fork and submit patches for review.

This opportunity for grievance remediation did not exist in the old world we’re describing, and contributed to the outcome that standard interfaces were the unholy logical union of each member’s opinions and beliefs.

I agree that the benefit of not doing work far outweighs the downsides, for most time horizons (If you’re thinking longer term than that, interface standards might be better for you. But few people are.

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

#300

Post by hutzlibu »

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…

"Perhaps the author just can’t see the value of it. "

Maybe so. But maybe he sees more the work of it.

If the project is activly developed, means it is probably not stable.

Documentation is only of value, if it is updated with the code.

Worse than no documentation is only wrong documentation.

So your explenation of the acronyms should remain true, but everything else maybe not. And it is work to figure out which is which and to verify, if a beginner comes and help with that.

So now while it would be nice, if they would have written better documentation in the first place, or merged your PR, they probably think just too high of the cost.

Post reply on HN