Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bti360.com

Post reply on HN
Print view View original

341–350 of 371 posts

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

#341

Post by marcus_holmes »

etripe wrote: post #318
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…

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?

I think the latter. We studied formal models of leadership and management. Knowing those really helped me to put some kind of structure on the things that I was dealing with, but ultimately dealing with them came down to interpersonal skills and "walking the walk".

One of the really useful-but-unexpected things was having some kind of head-canon for "what a manager is and isn't" and (in one case) "what a CEO should actually be doing". It was really helpful having a kind of connect-the-dots picture of what should be happening and therefore what dots needed to be connected to make that picture happen.

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

#342

Post by marcus_holmes »

Torwald wrote: post #332
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…

> and in those cases it's fine to hire a consultant to help. If I want to be that consultant, what area would be a good choice to become proficient in on that level?

Pick a single niche and become expert in that niche.

The more specific the niche, the less work you'll get but the higher you can charge for the work you do.

Get known as the expert in that niche. Write a blog on it, talk at conferences about it.

I don't know what areas would be good now, but I've hired consultants in scheduling problems, network setup and management, security, and recruitment.

If I had to pick an area that will never go out of style: security. Get good at being able to secure an online system and you'll never be hungry.

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

#343

Post by marcus_holmes »

lmm wrote: post #282
airstrike wrote: post #45

Earlier quoted context omitted.

Wow. This must be the very first pro-MBA comment in the history of HN. Feels refreshing!

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 default (for some reason).

If the MBA course is any good, it will at least have exposed such a person to other leadership styles and some management theory. They might reject it, of course, but at least they'll know it.

So, yeah, I don't think having an MBA makes you a better manager or leader automatically. But I think a manager who wants to get better could be helped by doing an MBA.

Of course, there are lots of managers who are convinced they don't need to get better, and so won't/can't be helped. And there are lots of people who get MBA's because it's a ticket to promotion and don't really care about the learning.

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

#344

Post by Kevguy »

yowlingcat wrote: post #336
Dirlewanger wrote: post #324

Earlier quoted context omitted.

Very well said. It's stuff like this that makes me think all CS majors need some sort of business communications requirement, something to at least give a foundation on how to speak to decision makers.

Good business communication is something you only learn by /doing/ it. Expecting a course to facilitate that is flawed. I'd be all for increasing the roles of internships in CS education in order to accomplish that -- and I have noticed that's begun to happen as well. CS majors these days have internships lined for summer and winter if not more (especially due to COVID). I am sure they'll learn a lot more than I did…

If it is a good course on business communication they _should_ be doing it - in class. And getting feedback and suggestions on improving with every attempt. Internships are a wonderful thing but many people don't realize how they are coming across so don't look to improve. There is some learning by osmosis, but mostly people keep doing what they have always done because it works (as far as they can tell).

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

#345

Post by marcus_holmes »

The_Colonel wrote: post #339
marcus_holmes wrote: post #317

Earlier quoted context omitted.

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 ;)

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 quarter and you're about to tell them that you need to reschedule because you got the architecture wrong on the first try - that is a business problem not an architectural problem.

The tech problems get a lot easier if you have some kind of framework for dealing with the business problems.

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

#346

Post by offtop5 »

6. Is by far the best career advice.

Instead of fighting and arguing all day, and getting fired anyway you can often just walk away from the situation. In fact I would say that's the only real conflict resolution that ever works.( In and outside of work )

Family not treating you right, don't complain about it on Reddit. A friend of mine ended up staying in a homeless shelter for a short while at 19 since he didn't like how his family was treating him. And he ended up with a great career after that.

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

#347

Post by closeparen »

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.

People high on our technical track don't spend their days on code. The job of a Staff, Sr. Staff, or Principal engineer is about coordination, negotiation, and consensus-building across bureaucratic distances. Most only look at architecture diagrams. Some review code. Vanishingly few contribute. When they do, the contribution is about keeping their skills fresh and their understanding of the project grounded in reality. It's not not what they're really getting paid for.

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

#348

Post by 121789 »

q-big wrote: post #304
astrange wrote: post #271

Earlier quoted context omitted.

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

That doesn't really jive with my personal experience, which is that contributors really don't want the only path to career progress to be a transition to management. I saw this happen firsthand at a consulting company--the technical side was pushing for the split, not the current level of management.

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

#349

Post by mcguire »

Tainnor wrote: post #306
mcguire wrote: post #237

Earlier quoted context omitted.

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…

True, it's not that the stacks and whatever don't matter at all, just that they'll change, you will have to learn new ones, and so any kind of religious attachment to one is a sign of an amateur programmer (in the Gerald Weinberg sense).

I, too, really like functional programming for that very reason. :-) It just isn't the approach I grew up with, and the functional programming manner of dealing with imperative is still a bit hard to get my head around.

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

#350

Post by mcguire »

yw3410 wrote: post #301
mcguire wrote: post #237

Earlier quoted context omitted.

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.

That is very true, and is the reason I was trying to find for lower-level, machine architecture and OS fundamentals.

Thanks!

Post reply on HN