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

251–260 of 371 posts

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

#251

Post by rileymat2 »

marcosdumay wrote: post #87
rileymat2 wrote: post #42

Earlier quoted context omitted.

This is interesting I did a bit of Googling, I guess it varies by sport quite a bit. https://www.post-gazette.com/sports/around-the-league-nfl/20... Some sports, most coaches came from players, but the NFL notably does not.

"Most coaches came fro players" is very different from "players are expected to become coaches". I can't think of any sport where players are expected to become coaches.

Oh, I agree, due to it being a pyramid only a fraction could ever become head coaches, so that wording was a stand in for that effect.

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

#252

Post by [deleted] »

mcguire wrote: post #240
xyzelement wrote: post #22

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…

[deleted]

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

#253

Post by horsawlarway »

nahname wrote: post #62
SPBS wrote: post #8

> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now i…

It's hard not to become jaded when every framework turns out to be just another team's personal preferences. I would say the statement is generally true about frameworks, but not true about rails. Perhaps the author did not spend enough time with rails.

Having spent time with Rails, I'd say you're biased.

I went from a dotnet shop to a rails shop, and despite the attitude that Rails is "marvelous", I can't help but feel like Rails is the bastard child of ASP.net.

It feels incredibly similar to working within the constraints of ASP - the framework knows best. Don't questions their choices. Don't do it any other way. Lock yourself into their good choices.

Their choices turn out not to be great for your use case? Fuck off.

Compounded by the fact that Rails is currently in the same death spiral dotnet was before scrapping everything and releasing dotnet core - Rails is great in v1. Rails is much less great in v6, where documentation is shoddy, splintered across versions, there are 5 ways to do anything, but god help you if you don't know the most recent incantation. Memorize all of our conventions, but hey - best practices have changed like 6 times in the last 10 years, so our conventions from yesteryear don't apply, and no, we won't update our documentation and stack overflow answers are bad/outdated.

Basically - Coming in from all sorts of other languages and frameworks I've used in prod (Golang, Dotnet, Dotnet Core, Node, Ts-Node, Rails, PHP, etc) Rails is currently sitting in my shitlist.

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

#254

Post by kortilla »

castlecrasher2 wrote: post #238
tnr23 wrote: post #227

Earlier quoted context omitted.

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

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.

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

#255

Post by toyg »

ddingus wrote: post #125
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…

It just occurred to me a sysadmin log would be very valuable: Installed update X to prevent risk Y Wrote script to advance process Z on input A Etc...

It would, but these logs can also feel like oppressive and meaningless bureaucracy. A lot of sysadmins are not even good at typing...

It’s one of those things that would probably be naturally suited to voice-activated systems (“Hey Siri, today I updated system X to avoid Y, and I wrote a script to improve process Z on input A” - 5 seconds to say, log saved in the right place, keywords like “updated” and “system X” recognised and formalized into some record, etc), if only such systems actually worked on any word beyond the most trivial (good luck with context-less mentions of pythons, rubies, native-american tribes who somehow serve pages of webs, androids in phones, etc etc).

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

#256

Post by kortilla »

noisy_boy wrote: post #71
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…

I think they are doing themselves a disservice by ignoring something that elevates overall understanding, ease of onboarding/troubleshooting and generally, the polish, of the project. I love documentation and usually manage to set aside time to add details in the README/wiki etc. It is a great way to share details with others and myself, six months down the line, because I don't have a super sharp memory.

It depends. A README for a custom TCP implementation does not need a section explaining what TCP is, that’s just clutter. Some types of projects are targeting a specific user group that has to have some level of knowledge.

Example: The readme for ripgrep does not explain what a shell is or how to pipe output.

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

#258

Post by aidenn0 »

duxup wrote: post #56
cmrdporcupine wrote: post #19

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

First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives. Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products. It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regu…

That VP is my hero. I've seen that story play out too often, but without the VP.

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

#259

Post by imhoguy »

SPBS wrote: post #8

> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now i…

> Is the author calling Rails as 'lock-in'?

I read '5. Beware of Lock-In' section as "be generalist".

It looks to me as generic career advice to not stay fixated to single all-in-one tech choice and role - SAP dev, Ruby dev etc. Ruby is just an example here ('even', 'frameworks too'), I guess the author witnessed the "rockstars" and evangelists hype wave of RoR circa 2005-2010. Possibly it could be e.g. ReactJS or Kubernetes today too.

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

#260

Post by chii »

that_guy_iain wrote: post #186
xyzelement wrote: post #22

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…

> 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 you code the right stuff. This seems to miss the point of teams. Everyone should have a role if you hire someone as a software engineer and they spend all their time doing devops becaus…

And yet, there's incentive for somebody (say, in soccer) to try and score a goal even tho it's not their role - because scoring a goal is rewarded to the individual.

Individual coders/contributors' compensation don't scale until they are shown to "score a goal". And yet, to do so, they may have to stop contributing in their usual, assigned role, but go "above and beyond" - such as redesigning the system, or to make their mark on the product and be recognized as such.

This, i find, is probably what the fundamental problem/friction with teams are.

Post reply on HN