Live data from Hacker News

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

bti360.com

261–270 of 371 posts

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

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

And over the last decade or so this has "trickled up" due to the interview process: experienced and even senior engineers are essentially funneled into the areas of focus you mention.

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

#262

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…

" Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage. " I'm skeptical. I mean, sure, for most people, the ability to convince a large number of other people to do things, to do your things, without worrying how they do it, is going to have more impact than any other contribution they could make. On the other hand, Van Jacobson's algorithm is like four lines of code (I…

I don't think we disagree. I hadn't heard of Van Jacobson but a quick glance at his wikipedia doesn't make it look like he was just a "pure coder" in the cartoonish sense of someone who doesn't know what's important and can't collaborate with others.

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

#263

Earlier quoted context omitted.

Let me paraphrase the original comment to make my next question easier to answer: Effective software engineering in a business context requires awareness of business needs. Which part of that is “bashing and shit talking”?

How about, Effective software engineering in a business context requires awareness of business needs as well as the technical skills to address those needs.

Nobody would argue with this.

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

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

Technical skills were greatly undervalued anytime past a couple of decades ago so it makes sense, at the time they were building their career there where no highly paid people who weren't manager types.

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

#265
post #201

Earlier quoted context omitted.

> No 46 year old wants to be doing the same thing for the same pay as a 26 year old. Why not? Being a T5 SWE at Google is (or at least it can be) pretty chill. It's a sweet spot for low stress and relatively high compensation. Why exactly do you need to "advance" your career, particularly if you don't want to be actually or effectively managing other people? The alternative is the "up or out" approach that drives eng…

L5 / "Senior Software Engineer" expectations are such that you have to have "influence beyond yourself", own some area of work, set technical direction for some other engineers. You're either a team lead or an "exceptionally strong individual contributor". It's not really that chill, and if you don't continue to do those things (lead or be exceptionally strong) that will show on your perf and therefore your compensat…

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

You're saying the expectation was to either become L5 or get out. So now we have all these PhDs and super achievers working at Google, but only some of them can be exceptional vs. the others.

You were exceptional vs. regular people and made it to L5. Now comes in a super achieving PhD that's a tad better than you and now he's exceptional. You are no longer exceptional. You're just an average super achiever. So get the eff off Google's lawn. Stack ranking completed.

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

#266
post #231

> Clean, understandable, and navigable code and design It's interesting to see "navigable" in here - I've struggled to articulate in the past this problem and I think this nails it. We often see simplicity come at the cost of "navigability". All the configuration by convention frameworks have this problem particularly heavily. I'm often at a complete loss to trace the mechanics of what is happening in things like vue…

what does navigable mean? I expect the IDE/tools to allow you to navigate the code fast and easily. If your IDE doesn't let you click-thru to definition, usages, and references, it's a poor setup imho.

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

#267

What I'd be really interested in is how tech churn is perceived by people older than me. I'm only 30 years in, so I tend to defend my generation's choices such as POSIX, SQL, XML, SOA, Java, and C/C++ before that (plus special-purpose pet peeves of mine such as markup/SGML and logic programming which came before) though I'm also claiming to be proficient in and generally open towards new tech. I consider most of supp…

Very interesting indeed and I had some glimpse of that in my dad, who all his life worked for only one company. And especially as I got older and interested in computers he started talking about some work stuff sometimes. His first programming language at work was 360 assembler. For the uninitiated/too young to remember: https://en.wikipedia.org/wiki/IBM_System/360. When I started working at the same company for my first job and I had to log into 'the host' - meaning the IBM mainframe they had (I believe by that time a Z series https://en.wikipedia.org/wiki/IBM_Z) I noticed how the custom login screen for their entire system had actually been written by my dad.

So all this just as a little context. But when I was talking about SQL like 15+ years ago he would always tell me that sure that's nice and all, but all those joins. They're painfully slow. Why would you do that? They had a table that had exactly all the information that they needed to have and they accessed it via a key. Fast and easy. Need a different view of the data? Make a new table that's organized the way you need it. Done and fast. Ring a bell? (NoSQL :))

I also started playing with Linux and system administration and obviously virtualization (vmware at the time, qemu stuff etc.). So I go talk to my dad about it and how I love the concept and how it does X and Y and Z cool thing. Yeah well, for him that was really old stuff, coz they had that on their mainframe since like forever (now called z/VM, then called VM/370 - in 1972).

We had to learn and use Java at university, which my dad always made fun of. Especially with articles like "The state of Java application middleware" and such that I was looking at. All that new fangled stuff, pah! He had been working with IBM CICS as the middleware for forever. Initial release of CICS July 8 1969, latest release June 12, 2020. (https://en.wikipedia.org/wiki/CICS)

I get it. I say the same thing(s) about some of the new fangled stuff I have to work with nowadays. With the kids. Some of it is great. Other things I'm just asked myself why the wheel had to be re-invented just to come back to square one. Like NoSQL databases that add features you'd expect from relational databases.

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

#268

3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand c…

>Assume the next person to maintain your code won’t be as smart as you. It's especially easy to assume this because I've often gone back to code I made a year or even months ago and barely understand it.

[deleted]

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

#269
I was pleasantly surprised by the list of "fundamentals". Here I was, expecting something rather specific about the discipline. And I'm so happy whatever I was expecting wasn't what was there. The qualities described do seem like true "fundamentals". It's a human effort after all.

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

#270
post #151

Earlier quoted context omitted.

I'm only 15 years in but have thought about this a lot. I agree with you that there is nothing new under the sun; that we just cycle back through old ideas; fashions come and go and come back. However, the environment changes so often old ideas go from being "possible" to "they just work" or "possible but really slow" to "instant". These environmental changes can make orders of magnitude differences, and cause old id…

Good points. Though if you've picked up computing from almost the ground up (soldering, hardware hacking, low-level programming, of which I did only a little however), there's that experience when sitting in front of an overwhelming, notebook-melting IDE where you say to yourself "I don't need all those arbitrary abstractions; I've got a pretty good understanding of what I want to achieve, thank you very much" and re…

IDEs and languages that an IDE can exploit are awesome. Especially if you don't really have such a good idea of a project (yet). It helps architects or contractors tremendously (as examples of people that might jump from one code base to another quite frequently).

What I mean is that I personally really like statically typed languages like Java and compile time safety. I even like some of 'verboseness' that people always complain about. I can take a modern IDE and a Java project that hasn't replaced everything with runtime magic yet (Spring comes to mind) and I can simply click my way through things to get the info I need and/or to build a mental model. However, I don't need a finished mental model already just to be effective at every task. Also refactorings that are really braindead simple and that you don't even have to think about are possible, precisely because they're simple and guaranteed to be correct.

Contrast that with other languages, such as Javascript, Python, Perl (yeah mentioning that because I loved Perl back when I was doing almost exclusively Perl - with a bit of shell scripting and lots of SQL - at my first 'real' job), where you have to have a mental model already and you have to know certain 'magic' to even be able to search for all the right things. Something that stuck in my head in that regard was AngularJS. I forgot the specifics but some type of identifier was use underscores in one place but dashes in another. How the eff am I supposed to find things easily? I have to know that magic conversion and grep for it specifically. If I come to a FE project written in Angular and have never done Angular, I will not find anything whatsoever and I have zero chance but to learn Angular to do basic things. And coming back to refactorings, even a simple rename can be a pain in the rear to do (and you won't do it and be stuck with really bad naming) because you can't be certain that you found all the right places to change until runtime i.e. your 2 a.m. batch run failed and you have users screaming at you. That teaches you to just stick with bad naming real fast.

Good languages and frameworks, if you ask me, allow someone that is senior in his role but a total noob with the specific language or framework to look at existing code and easily make certain modifications.

I wrote a simple T-SQL (Sybase, not MS-SQL) parser that output graphviz format to get a call graph of some backend job we had that consisted of a gazillion individual stored procedures strewn across a gazillion files and printed that and hung it up on the wall, just to be able to easily navigate that thing. Queue IDE where you just Ctrl-Click for the same end result.

Post reply on HN