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

#301

Post by yw3410 » Thu, Jan 07, 2021, 8:42 AM UTC

mcguire wrote: post #237

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…

Speaking as a career-long technical person, 1) All of those people aspects are very, very important. 2) Stacks don't matter. Languages don't matter. Editors/IDEs/whatever-the-hell-else doesn't matter. What I used to call a "firm theoretical grounding" does matter. What does that mean? At the base, the ability to write clear code that other people can read, and the ability to read code that other people have written.…

I think your points are good. Another point I would add is abstraction is a tool for managing complexity, not a tool for reducing knowledge.

You will have issues in that library/network/function/language. Learn to be comfortable peeling away the abstraction when you need to.

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

#302

Post by watwut » Thu, Jan 07, 2021, 9:05 AM UTC

closeparen wrote: post #275

tharkun__ wrote: post #265

Earlier quoted context omitted.

So are you basically describing stack ranking here? It's just impossible for everyone in a company to be a team lead, so not everyone can become that to become an L5. Which leaves the other option, to become an L5, which is to be an "exceptionally strong individual contributor" and being that "on an ongoing basis". Not everyone in a company can be an "exceptionally" strong person, otherwise it wouldn't be exceptional…

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

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

#303

Post by Tainnor » Thu, Jan 07, 2021, 9:07 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…

> 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 people who lack these skills despite their technical expertise), etc. but this statement I simply cannot agree with.

Everyone's experience is obviously different. Some people may work on problems where there are few legitimate technical challenges, or where they aren't solving any problems that haven't been solved before. That hasn't been my experience in most of the jobs I've had so far. There were significant architectural and sometimes even algorithmic challenges to be solved, and not solving them properly would mean either bugs or unmaintainable software.

ITT we talk about the importance of communication, but good coding patterns and architecture (as well as the right level of documentation) are part of communicating to other developers.

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

#304

Post by q-big » Thu, Jan 07, 2021, 9:15 AM UTC

astrange wrote: post #271

closeparen wrote: post #173

Earlier quoted context omitted.

This is the party line. It misses that “a day’s worth of code” is highly unequal across individuals. The people whose “day’s worth of code” are most valuable, quickly get pulled off of spending their days that way. It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will neve…

That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks. Which is not to say they're doing everything right.

> That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks.

Relevant: https://www.spakhm.com/p/parallel-tracks

"Why did all major software companies settle on parallel career tracks? To keep engineering managers from developing loyalty to engineers."

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

#305

Post by kstenerud » Thu, Jan 07, 2021, 9:19 AM UTC

kortilla wrote: post #254

castlecrasher2 wrote: post #238

Earlier quoted context omitted.

I'd like to hear an explanation for what seems to be an awful take. Why do you think this?

If your test loop depends on waiting for what sounds like an end to end test, the core problem is that you’re missing lower level functional/unit tests. Nobody should have to regularly wait for a server to install visual studio and oracle crap just to get feedback on a code change. Now this isn’t the sys admins fault at all. The sys admin definitely helped here but the devs still have a broken workflow.

This solution was designed to solve the whole package. The script is designed to run on BOTH a CI system and a standalone dev box (real or virtual), giving the same deterministic, stable environment so that everyone is always on the same page (Honestly I'm surprised this isn't done more often).

As a developer, you run the script once on your fresh Windows dev box, and then you can develop, run unit tests, or even run the CI script locally to have confidence that it will actually pass CI when you check your code in (and not overload the server with bad builds). In fact, I did all of my dev work in a VM because it's super easy to tear down and rebuild if I break the OS somehow or introduce an unexpected dependency ("it works on my machine" syndrome).

As an admin, you only have to include this one script onto a fresh Windows image, then run it and save the resulting VM image for the CI server to run (instead of installing everything on every run as part of the build script like they were doing).

The original issue was that everyone was using the CI server AS a dev environment because they couldn't get the project to build on a standalone box (it was tricky to set up, and undocumented, and the build scripts assumed a complicated CI environment). And management wasn't even raising a stink about this, despite the HUGE cost (in a large corporation I can understand this sort of thing falling through the cracks sometimes, but not in a small startup!). I'm actually not a sysadmin (I'm a developer), but I do hate inefficiencies like this enough to do something about it.

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

#306

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

mcguire wrote: post #237

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…

Speaking as a career-long technical person, 1) All of those people aspects are very, very important. 2) Stacks don't matter. Languages don't matter. Editors/IDEs/whatever-the-hell-else doesn't matter. What I used to call a "firm theoretical grounding" does matter. What does that mean? At the base, the ability to write clear code that other people can read, and the ability to read code that other people have written.…

> Stacks don't matter. Languages don't matter.

I only half agree with this. I agree that there is no one perfect language or stack and that there is a reason for there being so many alternatives. I also have worked with a fair share of languages and stacks by now and am not afraid of picking up any new technology when necessary.

But languages and stacks do have trade-offs. Sometimes the trade-offs can even be almost prohibitive (e.g. there are stacks I've worked on that were so immature they were a legitimate liability to the product and business, even if of course we would find some ways to mitigate them (but you can't mitigate something you're not even aware of)). In other situations, it depends a lot on the context: what languages/stacks does the team/company already know? What sorts of libraries are you going to use (there is no point in trying to use Ruby for an NLP project, for example)? Do you have special requirements in terms of performance, parallelism, etc. (that might exclude some languages)? And so on.

Agreed with the rest of your comment, and I want to add that "the ability to reason about a program in your head" is also why I tend to prefer functional programming with immutable values (even though, of course, that has its own set of trade-offs).

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

#307

Post by Tainnor » Thu, Jan 07, 2021, 9:34 AM UTC

codingdave wrote: post #48

mewpmewp2 wrote: post #36

Earlier quoted context omitted.

In which case are you not going to lock in building something like that? Even if you opt to go framework-less you are now locked in to whatever you are building.

This is somewhat true, but that is why separation of concerns is a best practice. Maybe you do have one piece of the stack "locked in" to Rails, but the rest of the stack can stay in place if you want to move from Rails to a different framework.

In Rails, this is unfortunately somewhat difficult (though not impossible) to achieve due e.g. to the autoloading magic that Rails adds and that can make isolating library code a bit more challenging if you're not aware of some intricate details of Ruby's and Rails's loading behaviours.

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

#308

Post by Cthulhu_ » Thu, Jan 07, 2021, 9:34 AM UTC

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…

Definitely. In my experience, the nitty gritty "labor" part of software development, the actual process of learning and writing code, gives great satisfaction and enjoyment. But after a few years, a few projects and / or jobs, and especially once your hard work is effectively thrown away in favor of something newer and shinier written and advocated by younger and louder people, you get more cynical.

But once you get over that, you realize that code itself is just an implementation detail, and it's the people higher up that have more influence. As developer you get paid an X amount a year, that's about it; as a higher up, you get to play with millions, both as money and as 'resources'.

As a developer you'll learn your limitations, that you cannot solve everything and that you alone are not good or fast enough to tackle nontrivial projects (currently in the middle of that, single developer, at the current rate it'll take years for my software to become viable. At least I'm on the payroll). If you have bigger ambitions, climbing the ladder is the way to go. Personally I'm hoping to be able to get a small team together in the coming year.

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

#309

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

asiachick wrote: post #284

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 are some example of things you learned getting your MBA?

There were lots of things I was curious about, like company financial records/statements, some of the legal stuff around employment. The accounting stuff was really useful.

But the real wins were the leadership and management units, to my mind. Learning the "formal" knowledge around this has really helped in subsequent management roles.

The entrepreneurship unit was vaguely hilarious, as I was running a blog for the local startup scene at the same time and neck-deep in Lean Startup, which no-one on the MBA course had heard of. Writing a really tight business plan seemed to be the hardest part of starting a business ;)

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

#310

Post by angarg12 » Thu, Jan 07, 2021, 9:38 AM UTC

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…

This is actually the much less known flip side of the Dunning–Kruger effect [1].

> Moreover, competent students tended to underestimate their own competence, because they erroneously presumed that tasks easy for them to perform were also easy for other people to perform.

[1] https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect#...