Live data from Hacker News

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

bti360.com

221–230 of 371 posts

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

#221
post #68

Earlier quoted context omitted.

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.

Interesting that your contractor jobs haven't also filled with non-technical, biz type work? Lack of desire to deal with accounting, client meetings, all the organizational aspects of running a business have kept me away from contracting or consulting. Might be time for me to revisit that, this being the year when I really think I need to start something new. I have no idea how to make that switch though. Are you con…

Typically, no. I almost always worked as an employee of a technical contractor---I was an IRS W-2 employee; they withheld taxes and provided (sometimes decent) health benefits (although I decided it was better to buy my own rather than changing insurance when I moved). I had no more than the usual accounting and organizational challenges.

For me, getting into it was easy. I packed off a resume to several of the local contracting companies. They pass the resumes to the ultimate company, who will do an interview (usually very low stress because it's easy to get rid of you) and then the contracting company and the employer work out all the details. (It may have changed, but at the time of my last such deal about 2005, the contracting company absorbed about 15% of what the end company was paying for you.)

Do realize that you need to keep at least 6-9 months of your income in a readily accessible account (savings, money market, or (whoo, I'm old) CD). I never went for more than a week before I could another job, but I have known people who had more trouble.

I have since gone into federal government contracting, which is another whole bag of stinky fish heads.

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

#222

Earlier quoted context omitted.

Interesting that your contractor jobs haven't also filled with non-technical, biz type work? Lack of desire to deal with accounting, client meetings, all the organizational aspects of running a business have kept me away from contracting or consulting. Might be time for me to revisit that, this being the year when I really think I need to start something new. I have no idea how to make that switch though. Are you con…

I've moved into contracting after being a software engineer/developer/team lead. Essentially since you are contracting, you are outside of the "bubble" where decisions regarding business get made. So while you may have important work on the project, you are not there when they are deciding on business aspects of it, you are usually not invited to any type of sales meetings or meetings with the clients. This is reserv…

This, exactly!

The down side is that you don't have any direct influence on those business decisions. (At one point, I wrote about three different login/single-sign-on clients for a web app infrastructure (including Kerberos/Active Directory) before they finally decided that SAML2 was politically/technically the right choice. Frustrating.) You do have indirect influence if you have a good relationship with your team lead, who will likely be a "real person", a real employee.

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

#223
post #144

Earlier quoted context omitted.

Interesting that your contractor jobs haven't also filled with non-technical, biz type work? Lack of desire to deal with accounting, client meetings, all the organizational aspects of running a business have kept me away from contracting or consulting. Might be time for me to revisit that, this being the year when I really think I need to start something new. I have no idea how to make that switch though. Are you con…

In the 2000's I did contractor work by myself (and occasionally hired a friend or two to get a project done). It was a disaster. I spent >50% of my time on client, non-technical work. I then joined a ~20 person firm in San Francisco and worked there for a few years purely coding. It was a joy. They had great business people, designers, copy writers, and then about a dozen great engineers, and I could just focus on th…

Yeah, I no interest in running my own consulting business.

In my case, it was usually a contracting company with 10-100 contractors working for one or more client companies, but the contractor had 0 day-to-day influence on the work I did. (I did try to pick up my paycheck in person and chat with the office staff.)

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

#224

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.

Believe it or not, checking if the candidate is able to dress professionally and appropriately for the occasion is one of the major things being tested on most white collar job interviews.

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

#225

This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…

There is a corollary to this - having a career of sideways moves and simply not progressing even in ways that are positive and to your liking because each move effectively puts you back to zero and companies taking advantage of the 'flat structure' myth to avoid having to provide career progression.

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

#226
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 think it is because the older you get you realize that all those projects are anyway just notches on some stick. For example everybody with some experience will choose a boring project with aweseom colleagues over a cutting edge project with a bunch of self-obsessed nerds. Life is short.

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

#227

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…

Tbh your achievement sounds like you added a lot of complexity (treating symptoms) instead of really trying to tackle the core of the problem.

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

#228
Some cynical lessons from 15 years in:

1. Politics is everything - how you are perceived is politics, whether you get assigned the projects you want is politics, career progression whether technical or managerial is entirely politics. You will be told various nonsenses about 'flat structures' and 'meritocracy' throughout your career but it's bollocks. Play the game badly and the flat structure is your career.

2. Most programmers don't care - as much as you might care about software engineering principles or even minimal levels of quality in your work, you will be shocked at the degree to which most of your colleagues do not. They might give lip service to it but when it comes to it most justify doing a crappy job by hand waving about being practical. If you talk even mildly about code quality expect to have it patronisingly explained to you 100 times over that you are a perfectionist and customers don't care and etc. Etc. (Of course these arguments are easily rebutted straw men but good luck getting that across).

3. Raising what's right usually hurts you - people do not like to hear uncomfortable or irritating truths. See point 1. Pointing out that something is a risk or severely broken is more likely to get you hassle and lower people's view of you and God help you if you are proven right - there is never a 'oh you were right!'. Nobody likes to be made to look bad. Again see 1.

4. Never underestimate how shit the code is in your next job - the interview very rarely gives you the slightest insight into the quality of a new employer's codebase and never be surprised at just how terrible it can be.

5. We'll fix it later means we will never fix it - technical debt is a lot like national debt - ever growing and rarely paid down. If you are fobbed off with a 'we will refactor that later' comment take that to mean 'this is shit and I am fine with that'.

6. Sideways shifts reset your career to zero - there is no such thing as treating development experience as fungable. You are only as good as your years in this particular slice of the industry and more often than not you are only as good as your years in this particular company.

7. Fuck you pay me - at any time if you are told by an employer that you are part of a family or that your pay rise couldn't happen because you are already paid highly for your title or other such nonsense, start looking for another job, you are being used.

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

#229

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…

I somewhat disagree with the way he connects simplicity and cleverness. I once had to explain the behavior of a particular subsystem. It was governed by a bunch of simple rules, but their combination created a complex behavior. This was similar to social insect colonies, where components (eg. ants) are driven by relatively simple rules, but the whole system exhibits remarkable "emergent behavior". What takes cleverne…

> I would say that being comfortable with complexity is a form laziness

I love this, and your comment in general!

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

#230
All good advice.

But all too often, the very best possible advice is, "Get out. Get out now!"

Get to a place where the Good Advice quoted above works. It can be very hard to tell that, up front. You have to try and see, and plan to skip along if you guessed wrong.

Most of my regrets, over 45 years in engineering, are over sticking around when what I had to offer was not what was welcome. Sometimes, what they needed, I didn't have. Other times, they didn't know what they needed, didn't want to know, and didn't recognize it under their noses. Either way, you would much better be elsewhere sooner than later.

For the young, it is tempting to try to prove your bosses wrong. That never, ever works. First, sometimes they aren't. When they are, they will be committed to not seeing it. It is always overwhelmingly better to deliver solutions to people eager to get them. So, find those people.

Often, you will have to prove yourself and the value of your ideas. That is not a reason to scram. But make sure before you start that success has a definition. "Ten times faster", "ten times cheaper", "ten times fewer server instances", "ten times less latency", "ten times less downtime" are hard to mistake, are remarkably often achievable, and are sometimes welcome.

In some cases, "two times" stands out; I recently got Quicksort to go twice as fast, and that drew some notice.

Post reply on HN