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

#361

Post by collyw » Fri, Jan 08, 2021, 9:25 AM UTC

one2know wrote: post #220

steve_adams_86 wrote: post #216

Earlier quoted context omitted.

I think what you're missing here is that the original comment isn't suggesting code doesn't solve problems when it counts. The thing is, developers often code things they never needed to. Or they code things off spec. Or they code things outside of the convention of what's appropriate for their immediate team or long-term needs of the product. The list goes on. Output could seem good for a long time before it becomes…

You have a very noob view of software engineering. You make a lot of generalizations about coders to support the theory that coding is low impact because coders fuck up a lot. Noob coders fuck up a lot. When I saved my company's ass those times, no non-technical people were present and it was wholly technical knowledge that solved it. I could have and probably should have ignored the problems and let the talkers try…

The tech lead at my place has just burned himself out and quit after making a load of poor decisions. He reinvents the wheel over and over again rather than use some prebuilt solution. I am going to have to maintain his undocumented, untested code. Experienced coders can be just as bad for over-engineering as noobs.

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

#362

Post by lolive » Fri, Jan 08, 2021, 9:39 AM UTC

marcosdumay wrote: post #235

lolive wrote: post #208

Earlier quoted context omitted.

The JavaScript fatigue is NOT a myth. [and CSS/layout is really tough, too]

All of that applies to frontend development too. At the end of the day, some people like Javascrip and CSS. And "full stack" only means that they will work with those, SQL, and some backend language (that may be Javascript too). It doesn't imply anything on the workload, all it does imply is that the place is hiring a generalist instead of specialists.

The last job offer that made me smile was for an AI / fullstack developper. Aka the platypus of software dev.

The problem is pretty simple. Let's say you are cutting-edge in all the technologies that make you very adaptable at time T. You get hired. You decide a stack A/B/C/... for your next project. You get stuck in that project for ... let's say 3 years. (a reasonable time for a project to reach production and have a few real-life iterations). If you are not an assh... who leaves after 2 years (leaving the production/maintenance to others, i.e never having lived the "hell" of maintaining things for real), then you are 3 years-behind in all the technologies that are not in the A/B/C/... stack.

Now, at time T+3, you are ... the obsolete man [for TTZ fans only :)]

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

#363

Post by collyw » Fri, Jan 08, 2021, 9:52 AM UTC

lmm wrote: post #360

marcus_holmes wrote: post #343

Earlier quoted context omitted.

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 d…

> 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 think even that part is disputed; we really don't know what a good manager looks like. Some of what's taught in MBA classes now is the opposite of what was previously taught, and there seem to be as many failure stories as success stories. I do take your point that m…

You know what a good manager looks like after they leave. It's like being a newsreader, you don't notice a good one but a bad one is very obvious.

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

#364

Post by lolive » Fri, Jan 08, 2021, 10:13 AM UTC

marcosdumay wrote: post #235

lolive wrote: post #208

Earlier quoted context omitted.

The JavaScript fatigue is NOT a myth. [and CSS/layout is really tough, too]

All of that applies to frontend development too. At the end of the day, some people like Javascrip and CSS. And "full stack" only means that they will work with those, SQL, and some backend language (that may be Javascript too). It doesn't imply anything on the workload, all it does imply is that the place is hiring a generalist instead of specialists.

Frontend has very few to do with HTML and CSS nowadays. It all has to do with framework choice, the build toolchain, the unit-testing of the front, the server-side rendering vs the client-side, the architectural layers (or bricks) to use on the client-side, SEO, performance, CI/CD, browser compatibility, components lifecycle (yumm, library versions upgrade!).

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

#365

Post by high_5 » Fri, Jan 08, 2021, 10:15 AM UTC

Buttons840 wrote: post #112

noir_lord wrote: post #90

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…

> 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? Option 3: Everything is on fire, be really quick to respond to your manager and then poke and prod at things in production until it kinda works, repeat daily. This guys a hard worker! I'll have to keep him in mind for a promotion.

And in the process burnout yourself. Quit the job or exit game of life.

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

#366

Post by ankurdhama » Fri, Jan 08, 2021, 11:42 AM UTC

trentnix wrote: post #58

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…

The the idea of simplicity in software engineering is one of those hand wavy stuff that the conventional wisdom is full of.

The simplicity (or the complexity) depends on what you want to do (requirements). If the requirements themselves are complex then expecting the code to be simple just doesn't make sense. Also piece of code would look simple to a person who has been working on it for long time and has the background knowledge vs a person who is new to the system.

Another thing to remember is that software systems are built incrementally i.e for each new requirement the developer have to figure out "how to implement this new requirement in this given code base with minimal changes" and this eventually will lead to complexity (unless you want to do big refactor on each new requirement).

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

#367

Post by yowlingcat » Fri, Jan 08, 2021, 2:20 PM UTC

Kevguy wrote: post #344

yowlingcat wrote: post #336

Earlier quoted context omitted.

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

> they _should_ be doing it - in class

They won't be doing it, they will be doing a simulation of it. How are they going to learn business communication without doing it in the context of a real business with a real P/L line and real consequences for good and bad execution?

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

#368

Post by astrange » Fri, Jan 08, 2021, 10:25 PM UTC

amzn-throw wrote: post #352

marcinzm wrote: post #85

Earlier quoted context omitted.

As I see it, the Amazon leadership principles are designed to select for jerks. Specifically jerks who make money. Just look at them. One or two out of fourteen indicate to not be a jerk (Earn Trust, maybe Hire and Develop the Best) while multiple other ones rewards you for being a jerk if you succeed (Disagree and Commit, Bias for Action, Insist on the Highest Standards, Are Right A Lot, Ownership, Deliver Results,…

You should read the descriptions[1] of those leadership principles, not just the titles. They're not what you think. Have Backbone; Disagree and Commit is specifically about NOT being a jerk who digs his heels in, and sabotages projects or decisions that they disagree with. Rather someone who is a team player and embraces the decisions of the group: Are Right A Lot is about constantly questioning your own understandi…

Are the names supposed to be ironic? Because what you said isn't the impression I got from reading them.

We have similar leadership principles with nicer names, although we don't use them to the point of bringing them up at meetings.

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

#369

Post by aquadrop » Sat, Jan 09, 2021, 4:48 PM UTC

peterangular wrote: post #138

nicoburns wrote: post #107

Earlier quoted context omitted.

> The action of wearing a suit (or tie for that matter) to an interview should never be seen as a "cultural fit" problem I would agree and would go as far to say that dress in general should never be a hiring criteria for a non-customer facing position. Unless there are hygiene issues or they are wearing something actively offensive.

I'm slightly more conservative - I've had people show up in t-shirt and jeans and have turned them away because I feel like they're breaking the social contract of what an interview is. Like - totally clean/non-offensive t-shirt and jeans. In a lot of my engineering roles I have had to be internal/external facing and do things like budget presentations, work with partners, etc. Before that, I was a general web/app de…

Ha, you "went ape" when someone saw as negative wearing a suit and you're doing the same in reverse. Bradley speaking, if you go to interview for lawyer position you wear suit, if you go to interview for developer position you don't wear a suit.

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

#370

Post by The_Colonel » Sun, Jan 10, 2021, 7:41 PM UTC

marcus_holmes wrote: post #354

The_Colonel wrote: post #351

Earlier quoted context omitted.

> 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. This works nicely on a small scale, but not with the architectural problems. > that is a business problem not an architectural problem It's an architectural problem because this business constraint forces me to get the architecture right the first t…

But there is a business reality where you can say "I don't know which architecture option is better, give me 3 months to do some prototyping and I can make a definite decision". But knowing how to frame that, and manage the expectations of the other people involved in that negotiation, and recognise their objectives and priorities, is a business skill. And, y'know, if you spend 2 years building a system on the wrong…

> But there is a business reality where you can say "I don't know which architecture option is better, give me 3 months to do some prototyping and I can make a definite decision".

And now back to your original claim. You need 3 months of prototyping only to reach a decision, but you still insist that it's an "easy" problem?

Then there's a problem that prototypes often don't uncover unknown unknowns. Investing effort into prototype improves your chances at arriving at correct solution but by no means guarantee it.