What I’ve Learned in 45 Years in the Software Industry • Hacker News Board

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

#351

Post by The_Colonel » Thu, Jan 07, 2021, 9:23 PM UTC

marcus_holmes wrote: post #345

The_Colonel wrote: post #339

Earlier quoted context omitted.

Now you talk about an algorithmic problem and there I agree with you - there isn't much algorithmic complexity in normal business coding. But in your previous post, you talked about architectural problems and there I disagree with you strongly. Taken in isolation, individual technology pieces are relatively simple and easy to evaluate. But when you plug in one such piece into a middle of a larger system (let's say ty…

Again, I get that this can be tricky. But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this. But the political and social problems of "we got it wrong, we're going to have to start again from scratch" are the real problems. Dealing with a marketing manager who has a product launch scheduled for the 2nd qu…

> But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this.

This works nicely on a small scale, but not with the architectural problems.

> that is a business problem not an architectural problem

It's an architectural problem because this business constraint forces me to get the architecture right the first time - I won't get another chance.

There's no business reality where it's OK to say "just give me another 2 years to re-do the system in a (probably) better way".

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

#352

Post by amzn-throw » Thu, Jan 07, 2021, 9:40 PM UTC

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

You should read the descriptions[1] of those leadership principles, not just the titles. They're not what you think.

Have Backbone; Disagree and Commit is specifically about NOT being a jerk who digs his heels in, and sabotages projects or decisions that they disagree with. Rather someone who is a team player and embraces the decisions of the group:

Are Right A Lot is about constantly questioning your own understanding and being CAPABLE of changing your mind. We literally interview for it by asking about a time your mind was changed on something important.

Ownership is about not saying "That's not my job". If there is some work to be done, and nobody's doing it, don't have a high and mighty attitude about it being beneath you. Just get it done. (e.g. Developers doing QA, Ops, Documentation, etc)

Bias For Action is about taking calculated risks.

Insist on the Highest Standards is the only one that I know jerks abuse.

[1] https://amazon.jobs/en/internal/principles

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

#353

Post by amzn-throw » Thu, Jan 07, 2021, 9:42 PM UTC

marcinzm wrote: post #21

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…

>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 is what FAANG interview generally look for so why is it a surprise that potential hires focus on it? Amazon literally says that you need to highlight all the leadership principles in the stories you tell when answering behavioral questions.…

Amazon asks senior engineers MORE leadership/behavioural questions.

But no, you don't need to memorize the leadership principles themselves, and your individual stories can't highlight ALL the leadership principles. Some of them are deliberately in conflict with another.

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

#354

Post by marcus_holmes » Thu, Jan 07, 2021, 9:43 PM UTC

The_Colonel wrote: post #351

marcus_holmes wrote: post #345

Earlier quoted context omitted.

Again, I get that this can be tricky. But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this. But the political and social problems of "we got it wrong, we're going to have to start again from scratch" are the real problems. Dealing with a marketing manager who has a product launch scheduled for the 2nd qu…

> But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this. This works nicely on a small scale, but not with the architectural problems. > that is a business problem not an architectural problem It's an architectural problem because this business constraint forces me to get the architecture right the first t…

But there is a business reality where you can say "I don't know which architecture option is better, give me 3 months to do some prototyping and I can make a definite decision".

But knowing how to frame that, and manage the expectations of the other people involved in that negotiation, and recognise their objectives and priorities, is a business skill.

And, y'know, if you spend 2 years building a system on the wrong architecture because you didn't know how to ask for more time to make a better decision in the first place... well, you need some management training ;)

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

#355

Post by closeparen » Thu, Jan 07, 2021, 11:07 PM UTC

watwut wrote: post #302

closeparen wrote: post #275

Earlier quoted context omitted.

Two years is a long time to stay in one job. Two years is an eternity for a team's headcount not to grow. It's virtually certain that you'll be a mentor to several new hires in that time. You'll also have a long head start on understanding the codebase and tools relative to many others who will be working with them. If you're not some kind of leader at that point, something's wrong. Unless you found one of those rare…

> Two years is an eternity for a team's headcount not to grow. Teams do not expand until infinity. In fact, it is often better for teams to not expand. If you are expected to be leader after two years, because the teams are expanding regardless of whether more people are needed and because everyone else is fresh new, then there is issue with managemet

Where do you think the crazy stock growth for the entire tech industry over the last 10 years is coming from? Having a massive backlog of productive opportunities, scaling up to execute on more and more of them in parallel.

I don’t expect that to last forever, but it’s the context that this system is built for.

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

#356

Post by potta_coffee » Thu, Jan 07, 2021, 11:23 PM UTC

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…

I think this is on point but I've work with a lot of MBA's with garbage people skills. I'm not sold on the value of MBA except as a piece of paper on a resume. I'm not claiming that it is entirely not useful, but I don't believe it necessarily means someone is qualified either.

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

#357

Post by potta_coffee » Thu, Jan 07, 2021, 11:45 PM UTC

nicoburns wrote: post #44

peterangular wrote: post #35

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 was treated poorly and mocked at an interview for wearing a sports coat over my jeans and t-shirt. Just can't win sometimes. In the end, not the kind of place I wanted to work.

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

#358

Post by potta_coffee » Thu, Jan 07, 2021, 11:47 PM UTC

peterangular wrote: post #138

nicoburns wrote: post #107

Earlier quoted context omitted.

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

I'm slightly more conservative - I've had people show up in t-shirt and jeans and have turned them away because I feel like they're breaking the social contract of what an interview is. Like - totally clean/non-offensive t-shirt and jeans. In a lot of my engineering roles I have had to be internal/external facing and do things like budget presentations, work with partners, etc. Before that, I was a general web/app de…

I think nowadays it would be fair to tell applicants what is expected for an interview in regards to dress. I've been judged for underdressing and for overdressing. Just can't win and it's unfair to expect someone to read your mind.

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

#359

Post by potta_coffee » Fri, Jan 08, 2021, 12:57 AM UTC

kstenerud wrote: post #129

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…

I've been bitten by this. I once worked at a place where the development process for the Windows version of their product was GLACIAL because there was no way to run the CI scripts locally or even set up a dev environment that could build the product. People actually edited code in a text editor and then submitted it to github and waited an hour for the CI job to build a virtual Windows instance, run updates, install…

I solved a bug at my company that was costing $10k per month. The whole thing was not acknowledged because the leaders were embarrassed and probably afraid of repercussions for not realizing they were pouring that much money down the drain. (this was at a small company). Then I was sidelined by the CEO (a marketing guy) because I wasn't "senior enough" to do the job, whatever that means. I wasn't good enough, but the system I built for them is apparently still running several years after I left and looks the same.

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

#360

Post by lmm » Fri, Jan 08, 2021, 1:37 AM UTC

marcus_holmes wrote: post #343

lmm wrote: post #282

Earlier quoted context omitted.

I think everyone agrees that bad management is the biggest problem facing a lot of software companies. The part that's disputed is whether managers with MBAs are actually any better than managers without them.

I've been pondering this. I think an MBA will help you be a better manager if you want to be, because at least there's some clue about what a "good" manager should look like. I've met sooo many bad managers. In most cases they were bad because they didn't really know what they were doing and they felt they couldn't look "weak" or not be in charge. There's always the urge to authoritarian leadership because it's the d…

> I think an MBA will help you be a better manager if you want to be, because at least there's some clue about what a "good" manager should look like.

I think even that part is disputed; we really don't know what a good manager looks like. Some of what's taught in MBA classes now is the opposite of what was previously taught, and there seem to be as many failure stories as success stories. I do take your point that maybe just thinking about anything other than the authoritarian mode is enough to raise a manager above the average, which is distressingly plausible.