Live data from Hacker News

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

bti360.com

151–160 of 371 posts

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

#151

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…

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 ideas to suddenly feel very different in practice.

When I think of programming languages for example, of the languages you mention, a lot of their design (like matched brackets in XML), were decisions that made a lot of sense when we had monochrome editors, but now with extremely fast and advanced IDEs, we can take old PL ideas from the 50's and design languages with IDEs in mind that are a lot less cryptic and concise.

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

#152

Cool article. That suit...that hair... He doesn’t really deliver any “wise mountaintop guru” stuff, though. Just shows that good old-fashioned common sense is timeless (and distressingly rare).

I loved the article too. I mean, the most important wisdom is never "mountaintop guru" insight, it's always simple things that just need to be reinforced and actually observed in practice. It's one thing to say "keep it simple" and a totally other thing to actually be keeping it simple for four decades :)

> reinforced

Agreed. I'm ~15 years in, and so even though I didn't come across any new ideas here, it's very helpful to hear what a 40 year vet thinks are the most important signals and try and harden those paths in my mind.

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

#153
post #23

Stuff I'd add that I think is crucial, and all related to one topic: good writing! 1. Learn to write specs Call it an RFC, call it a PRD, call it whatever. Writing out a plan for any project taking around a week or more is always worth it. Use it to establish scope and priorities. Keep a "Questions" section that you whittle away at as you seek out feedback. Make the body a hierarchy of design tasks and implementation…

Do you happen to know of a properly written (publicly available) spec? I'd love to see a good example.

This is a nice essay introduction depending on the type of spec you want to write:

https://www.joelonsoftware.com/2000/10/02/painless-functiona...

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

#154
This is really good advice. Myself personally, I have been programming for decades as well and struggle with the curse of knowledge.

Curious what other people do and what struggles they have had.

Having spent time studying Category Theory I see a lot of value to using it in my code but it is not common knowledge and often confuses others when you start throwing around terms like functor, monoid, monad, etc.

At the same time I don't want to write code that isn't as reusable or to that isn't as maintainable.

Are we as an industry limiting our own potential by deliberately not using knowledge when it is beneficial for the sake of greater communication?

My personal philosophy when working with teams is to exclude some of that stuff but slowly introduce it and train junior developers on some of the concepts in the hope that I can push that knowledge forward.

Curious what others think of this dilemma and how they address it.

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

#155

Earlier quoted context omitted.

Found the manager. This is just more developer hate drivel. Yes, if you think managers are more valuable, then obviously you are going to say engineering work is "incredibly limited" and manager activities are "orders of magnitude more impactful" Listen, no amount of ass kissing and brown nosing is going to solve actual tech problems.

This tone is unwelcome on HN, which is probably why your previous comments have often been downvoted and flagged.

Bashing and shit talking software engineering profession is welcome on HN?

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

#156

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…

I would expect it to depend upon the company.

Dress code doesn't really factor for me, but I've worked for the same place for a while now and we've always been 95% remote. Half of us just wear whatever we slept in the night before. Most people don't get dressed until lunch time. Even in the office it doesn't get much fancier than a t-shirt and jeans. I guess our tech lead wears a button down shirt, but his jeans usually have giant holes in them, so I would call that a wash.

Expecting an interview candidate to wear something nice would feel a bit hypocritical.

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

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

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…

It’s ok to just produce a days worth of code in a day. This is not a failure mode or something to be avoided. It’s ok to just work a job. Not everyone is focused on “impact” and all that junk, and nor does everyone need to be.

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

#158
post #146

Earlier quoted context omitted.

That guy could perfectly be some tech lead, establishing his rock solid approaches on team of junior 4-10 engineers and delivering rock solid new products.

I didn't say it outright but I picked this guy as an example as ... hey ABSOLUTELY did not want to lead anyone / should not lead anyone. Very much the high performer type who SHOULD NOT 'progress' to management or supervisor or ... reviewer of any sort. He was professional, but "prickly". I found the keys to get along with him but a lot of folks didn't have the patience.

If he doesn't want, it is one story.

Another story may be because he may not be promotable to such position because of mentioned "prickly" behavior, which may or may be not just engineering honesty and straightforward approach in contrast to bs(sugarcoating, ass kissing, exaggregating, sweeping dirt under carpet, etc) culture established in many companies.

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

#159

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…

I think this is fair to both sides. I dress casually for interviews not only because that is what I prefer to wear but also in hopes of getting rejected by anybody who would consider that a red flag.

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

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

[deleted]
Post reply on HN