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

#311

Post by marcus_holmes » Thu, Jan 07, 2021, 9:46 AM UTC

Tainnor wrote: post #303

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…

> 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. I'm totally on board with highlighting the importance of communication, team work, people skills (and I've seen how awful it is to work with…

> There were significant architectural and sometimes even algorithmic challenges to be solved, and not solving them properly would mean either bugs or unmaintainable software.

I get that, and I don't mean to suggest that some bits of this aren't tricky.

But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to get that right first time.

There are lots of management and people problems where none of this is true and it's very much a "known unknown" that has to be got right on the first try, without knowing all the possible tradeoffs or consequences, and under time pressure.

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

#312

Post by YeGoblynQueenne » Thu, Jan 07, 2021, 9:52 AM UTC

>> 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. Smart people who are comfortable with complexity can be especially prone to it!

The more I learn about smart people, the more I realise how dumb they are.

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

#313

Post by tannhaeuser » Thu, Jan 07, 2021, 9:58 AM UTC

gen220 wrote: post #299

dodobirdlord wrote: post #287

Earlier quoted context omitted.

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…

I'm glad you've added that last paragraph, because I had the impression you'd welcome our new F/OSS overlords, even though I factually agree with your point about open implementations having replaced open standards.

What I mean is that, while people love to argue about F/OSS free vs open licenses nuances ad infinitum, the reality is that power has shifted to a very small number of players (FAANG, RedHat/IBM, MS et al) who've captured F/OSS, without choice, discussion, evolution (of competing ideas). What you call "design by committee" can alternatively be seen as a defense against unilateralism with the power dynamics we've headed into.

"Open implementations" means nobody can make a buck and sustain development and innovation. The only gain to be made is through integration and attention economy, creating perverse incentives.

Take Linux: they're trying to implement an operating system for like 30 years now in a monolithic fashion. The power of Unix is not that it's the most advanced operating system, even by 1970s standards, but that it is a minimal portable system that can be created from scratch in one or two years.

Linux being GPL hasn't prevented it from being used for a giant spynet (Android) nor a lock-in scheme ("the Cloud", k8s) taking Unix principles of site autonomy and small parts working together ad absurdum (the absurd part being that to shield against minor F/OSS version conflicts we need opaque almighty container orchestration and an accompanying zoo of tools, all the while we're doing largely the same we did 20 years ago on much less capable hardware).

Take so-called web standards: the idea of standardization is originally motivated by digital humanism, eg. that we do the best we can to come up with idioms and languages for digital communication and its preservation, accepting inclusion over perfection. The reality is that this idea has been usurped by an ad company taking all communication into an analytics-heavy medium more idiosyncratic than ever, leaving a single browser capable to render web content in its entirety, where "standards" (HTML, http) are created by the dev team of said browser. We didn't need that; we had CompuServe, AOL, and desktop operating systems for this purpose.

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

#314

Post by randomswede » Thu, Jan 07, 2021, 10:11 AM UTC

Alex3917 wrote: post #91

marcosdumay wrote: post #87

Earlier quoted context omitted.

"Most coaches came fro players" is very different from "players are expected to become coaches". I can't think of any sport where players are expected to become coaches.

> I can't think of any sport where players are expected to become coaches. In amateur sports it's common. E.g. in rowing, cycling, fencing, cross country skiing, etc., people are generally expected to coach at some point. Albeit usually while they're doing the sport, and not necessarily as their primary careers.

To some extent, coaching something you practice is good for giving you another perspective on what it is you're practicing. In an ideal world, this will elevate your skill level.

This does, however, not necessarily mean that everyone is a good coach, nor does it mean that everyone should stop practicing what they're doing and focus solely on coaching.

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

#315

Post by Tainnor » Thu, Jan 07, 2021, 10:21 AM UTC

marcus_holmes wrote: post #311

Tainnor wrote: post #303

Earlier quoted context omitted.

> 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. I'm totally on board with highlighting the importance of communication, team work, people skills (and I've seen how awful it is to work with…

> There were significant architectural and sometimes even algorithmic challenges to be solved, and not solving them properly would mean either bugs or unmaintainable software. I get that, and I don't mean to suggest that some bits of this aren't tricky. But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can m…

> But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to get that right first time.

No, I disagree. Some problems are truly novel (or maybe, there are just a handful of competitors and you obviously can't see their source code) and you just don't even know what kinds of solutions might exist. There might be bits and pieces in the research literature, but good luck even finding them, let alone understand if they are applicable. The space of possible technical and architectural solutions is infinite-dimensional, so it's not always a "known known" issue. There might be crazy solutions out there that you simply didn't think of.

Now, if it's about "create a CRUD interface to you e-commerce store", then I agree that the situation is more similar to what you described, but that's not what everyone is working on.

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

#316

Post by duckmysick » Thu, Jan 07, 2021, 10:21 AM UTC

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…

> When learning something new, keep a dedicated list of "this looks like magic!" items. Use your "down time" to research items on this list instead of refreshing your favorite news aggregator.

Brilliant advice. It's also applicable to other areas of life, not just programming.

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

#317

Post by marcus_holmes » Thu, Jan 07, 2021, 10:52 AM UTC

Tainnor wrote: post #315

marcus_holmes wrote: post #311

Earlier quoted context omitted.

> There were significant architectural and sometimes even algorithmic challenges to be solved, and not solving them properly would mean either bugs or unmaintainable software. I get that, and I don't mean to suggest that some bits of this aren't tricky. But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can m…

> But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to…

I had to work on a scheduling problem once that involved going to a university to talk to Comp Sci PHD's who were working on similar problems. That was fun. In 25+ years of commercial coding, that's happened once ;)

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

#318

Post by etripe » Thu, Jan 07, 2021, 11:00 AM 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…

Did you find the MBA trained you to solve those people problems better? Did you get any practical, hands-on experience dealing with people problems during its course, or did it provide an interpretational framework, with true learning follow afterwards, like with a programming degree?

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

#319

Post by tremon » Thu, Jan 07, 2021, 11:17 AM UTC

asiachick wrote: post #283

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…

I'm not sure how "(a) work independently" fits. In fact it seems the opposite. The whole point is about working with and influencing others. That's not "working independently"

"Working independently" is not the same as "working in isolation". Not sure that this is also what the GP meant, but "work independently" usually means that you understand what the business needs and can initiate new tasks on your own, without waiting for someone to tell you what to do.

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

#320

Post by tremon » Thu, Jan 07, 2021, 11:52 AM UTC

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…

To me, quirks are "yellow flags" in the interview stage because it means that you're not able to put your own weirdness aside to fit socially when you arguably need to the most

My response from the other side of the table: as an interviewee, I view these initial interviews an an exercise in expectation management. I don't consider myself as weird, so I act like I normally would, otherwise I'm setting myself up for failure later on.

Also, I don't wear to an interview what I wouldn't be comfortable wearing on a normal working day. I dress casual on purpose (but representably casual, not weird casual -- but that's my personal opinion of course).