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

#211

Post by tannhaeuser » Wed, Jan 06, 2021, 8:56 PM UTC

breck wrote: post #151

tannhaeuser wrote: post #81

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

Good points. Though if you've picked up computing from almost the ground up (soldering, hardware hacking, low-level programming, of which I did only a little however), there's that experience when sitting in front of an overwhelming, notebook-melting IDE where you say to yourself "I don't need all those arbitrary abstractions; I've got a pretty good understanding of what I want to achieve, thank you very much" and realize the cognitive overhead can become a net-negative compared to the perceived problems that modern IDEs are attempting to solve. Matter of taste, of course.

As to XML, matched end-element tags (if that's what you mean) actually were a simplification compared to SGML from which XML was derived/subset. In SGML, you can omit/infer end-element tags or can type "" to make SGML auto-close the most recent element. I agree the verbose-ness of XML looks especially redundant since it's always the most recent element you have to close anyway whereas SGML (in principle, at least) has overlapping ("concurrent") markup. And I can assure you that around 1998 we had 32bit color monitors and IDEs didn't look all that different from today ;)

But back to the topic, I believe a lot of material has simply vanished from the 'net, or isn't accessible through search engines anymore.

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

#212

Post by twh270 » Wed, Jan 06, 2021, 9:00 PM UTC

tannhaeuser wrote: post #81

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 30 years into this industry also. We all have a tendency to defend and use what we're comfortable with, which often is what we learned ages ago. I try to challenge myself regularly by looking for my biases and assumptions. (Easier said than done, of course.)

However, I'd say the rate of "tech churn" has become impossible to keep up with in the most popular stacks (Java[Spring], .NET, front-end, Node). If you are in other areas, things tend to move slower.

I think the initiatives for standardization move at about the same rate as they used to, but the increasing amount of industry churn makes it seem like standardization has slowed down.

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

#213

Post by one2know » Wed, Jan 06, 2021, 9:01 PM UTC

usefulcat wrote: post #185

one2know wrote: post #102

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.

It sounds like you're making assumptions in bad faith. I'm a SWE (i.e., not a manager) and I didn't read the comment at all like you did. On the contrary, I quite agree with it.

Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars I think technical solutions are orders of magnitude more impactful and foofoo talk bullshit is incredibly limited. So I guess we will have to agree to disagree. Maybe noob coders "produce a day's worth of code" and that's all they can do, that's your perspective.

I've sat through dumb two hour meetings about deciding which words in a document should be capitalized. Is that what is meant by "make sure your team/business is doing the right things?"

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

#214

Post by samatman » Wed, Jan 06, 2021, 9:14 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…

This is in fact the advantage of having a widely-understood dress code for things such as interviews: that way no one has to play guessing games, you just show up as expected and it's one less thing to think about.

Unfortunately, our industry has no such thing, so I always ask before an interview. So far the answer is always "uh, we just wear normal clothes", "casual is fine" or once "just wear clothes, please, this isn't quite Burning Man" (ended up working at the last place), but: this was in the Bay Area, so YMMV.

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

#215

Post by tannhaeuser » Wed, Jan 06, 2021, 9:15 PM UTC

waldrews wrote: post #184

tannhaeuser wrote: post #81

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…

Curious how logic programming fits in with the rest of that list?

Why wouldn't it? I've always been a fan of polyglot programming and use of languages oriented towards specific use cases, as opposed to language-centric ecosystems. Now Java doesn't exactly fit that criterion ;( but makes up for it by being portable, relatively open, and cross-platform, and being instrumental in having prevented Windows dominance on the server-side in the 1990s. And it pays the bills. Haven't used it for new personal projects since 2008 or so, though.

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

#216

Post by steve_adams_86 » Wed, Jan 06, 2021, 9:22 PM UTC

one2know wrote: post #213

usefulcat wrote: post #185

Earlier quoted context omitted.

It sounds like you're making assumptions in bad faith. I'm a SWE (i.e., not a manager) and I didn't read the comment at all like you did. On the contrary, I quite agree with it.

Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars I think technical solutions are orders of magnitude more impactful and foofoo talk bullshit is incredibly limited. So I guess we will have to agree to disagree. Maybe noob coders "produce a day's worth of code" and that's all they can do, that's your perspective. I've sat through dumb two hour meetings about deciding whi…

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 problematic, then the pure coder simply codes more to solve those problems. This is very circular and makes up a lot of work done by software developers in my experience.

I agree with what you're saying in part. Pure coding skills are essential, especially in critical situations like that. Soft skills won't fix broken things, for example. Salespeople can't deliver the features they promise without someone to develop them.

However, soft skills can help someone with excellent coding skills to know what to apply their skills to and when, and how to integrate their skills within a broad team of different disciplines.

This is arguably true in any field; I think it's often missed in software development because people have such a difficult time distinguishing boundaries of things. The problems you're solving, when you're passively or actively solving problems, when output is applicable to a specific problem, etc. Even software engineers themselves struggle with this.

Your ability to save your company's ass is an excellent skill to have, but it isn't directly related or exclusive to what the original comment was saying.

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

#217

Post by [deleted] » Wed, Jan 06, 2021, 9:23 PM UTC

lrossi wrote: 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…

[deleted]

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

#218

Post by steve_adams_86 » Wed, Jan 06, 2021, 9:27 PM UTC

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…

I saw a reference to Ruby, but not Rails. Are you inferring Rails from the mention of Frameworks towards the end?

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

#219

Post by Leherenn » Wed, Jan 06, 2021, 9:28 PM UTC

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.

Football/soccer? Of course there are more players than coaches so they can't all become coaches, but I would say star players are expected to become coaches, and lots of them do.

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

#220

Post by one2know » Wed, Jan 06, 2021, 9:36 PM UTC

steve_adams_86 wrote: post #216

one2know wrote: post #213

Earlier quoted context omitted.

Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars I think technical solutions are orders of magnitude more impactful and foofoo talk bullshit is incredibly limited. So I guess we will have to agree to disagree. Maybe noob coders "produce a day's worth of code" and that's all they can do, that's your perspective. I've sat through dumb two hour meetings about deciding whi…

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 to fix it and take the blame for millions in losses. So it is very apropos to the original comment.