Live data from Hacker News

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

bti360.com

61–70 of 371 posts

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

#61

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 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 110% normal that someone puts on a nice suit for an interview. The action of wearing a suit (or tie for that matter) to an interview should never be seen as a "cultural fit" problem - I'm looking at you SV...

Sorry that almost happened to you. That's some bullshit.

---

Overall a nice well-fitting button down + a pair of well-fitting dress slacks is what I would recommend. Personally, I wear a slim fit brand new white button-down (ironed), nice dark blue chinos (ironed, not pleated), and not-scuffed brown wing-tips. Often I also wear a tie, but am considering not thanks to a derelict SF "big-wig" grilling me in an interview as to "why are you wearing a tie?" All I wanted to say is "does it matter?" (offender: you're reading this don't do that again.)

Also get a solid hair cut, ensure you're shaved if male, and yeah - sit up and be confident while you're in the chair. Body language does matter, and your interviewer will subconsciously notice regardless if they're giving you a "pass" or not.

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

#62
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's hard not to become jaded when every framework turns out to be just another team's personal preferences. I would say the statement is generally true about frameworks, but not true about rails. Perhaps the author did not spend enough time with rails.

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

#64

Earlier quoted context omitted.

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.

Also the division of roles is far more specialized than say basketball. Only the QB might have a near/full picture.

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

#65
post #23

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.

The operation manual of the original IBM PC from 1981 is a very good example.

Personal plug: I wrote an article about writing specs a while back. I use the IBM PC spec as an example, so you might find my article useful.

https://iskender.ee/2020/06/18/EE-Specs.html

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

#66
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…

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, deploy and maintain. Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.

This was exactly the experience I had not so long ago.

Management brought in a new "team leader" to "shake things up" with "new ideas."

She spent most of her time reading management books, taking online management courses, and going to management seminars. She almost never spoke to the "team," and when she did, treated us like underlings.

They gave her two years to make a difference, and then kicked her out in the first round of COVID cuts.

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

#67
It was good to read this... But today most of the big/famous companies (except Tier 1s) aren't giving importance to these. Infect in one of JDs of a big company for Engineering manager role I saw "Ability to negotiate" as a requirement skill for that job. I would blame the fast-fail culture brought up recently.

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

#68

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.

There are other paths at Google than upgrading to mgmt, but all of them involve "cross-team collaboration" and other quasi-political (with a small-p) aspects. Actually just writing code at Google is, from my experience, a small part of the job and not rewarded. The faster you get out of writing code and get into designing and delegating it, the better you're off. Sucks if you don't like it. Coming up with a way to re…

Over the course of a number of years and a few jobs at IBM starting in the early 90s, I knew 2 people on their "technical track". Their jobs involved huge numbers of airline miles, continual meetings, and essentially no technical work.

That was one of the primary reasons I stayed a contractor most of my career.

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

#69

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 brain damage/CTE has something to do with it.

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

#70

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…

Agree. One of the most important skills is the one he describes like this: >> The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated. In my experience (35 years), this isn't just about knowing the right way to describe things, it's also understanding what things to concentrate on when communicating, and what to ignore. If you are a tech pers…

Yup. I agree with you (and your pragmatic approach to helping the raptors!)
Post reply on HN