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

#331

Post by nahname » Thu, Jan 07, 2021, 2:30 PM UTC

BossingAround wrote: post #95

nahname wrote: post #62

Earlier quoted context omitted.

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.

> It's hard not to become jaded when every framework turns out to be just another team's personal preferences. Isn't that a definition of a framework? A more or less opinionated way to structure a particular type of an application?

Too many are... Some are built upon a novel ideas though. Can we build web apps like desktop apps? Can we use one language on the frontend and the backend? Can we write everything in java?

Rails was built upon the novel idea of, "Can we build a CRUD app framework developers enjoy using?". As there is no silver bullet, this comes with tradeoffs many do not want. Performance is not a first class citizen. Code is prescriptive. A lot of rails apps are just gluing together gems.

I will say though, if you are building a CRUD app. There is no other option that will get you to done faster than rails.

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

#332

Post by Torwald » Thu, Jan 07, 2021, 2:40 PM UTC

marcus_holmes wrote: post #43

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…

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?

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

#333

Post by gen220 » Thu, Jan 07, 2021, 3:02 PM UTC

tannhaeuser wrote: post #313

gen220 wrote: post #299

Earlier quoted context omitted.

Adding on to your point, the phrase “designed by committee” carries a strong negative connotations for a reason. People may have some gripes with the implementation of some subsystems, but they are free to fork and submit patches for review. This opportunity for grievance remediation did not exist in the old world we’re describing, and contributed to the outcome that standard interfaces were the unholy logical union…

I'm glad you've added that last paragraph, because I had the impression you'd welcome our new F/OSS overlords, even though I factually agree with your point about open implementations having replaced open standards. What I mean is that, while people love to argue about F/OSS free vs open licenses nuances ad infinitum, the reality is that power has shifted to a very small number of players (FAANG, RedHat/IBM, MS et al…

Oh yeah, I totally agree that the long term picture here is quite murky at best and frightening at worst.

> “Open implementations" means nobody can make a buck and sustain development and innovation. The only gain to be made is through integration and attention economy, creating perverse incentives.

I don’t know if I wholly agree with this point.

Especially in the most recent decade, we’ve seen a lot of the F/OSS developed at attention economy companies applied to completely disjoint industry sectors, with positive effect.

I work at an insurance company, for instance. The fact that we’re using gRPC/protobufs allows us to have a small engineering team that hits way beyond our headcount. Happy to elaborate more on the point, but I’ll leave it here in good faith.

I think that our dependence on this technology is a smart choice in the short to medium term. In the long term (10+ year), the worst case scenario is that we have to maintain a fork, or migrate to something more secure. We would have had to do this anyway, if we built our own RPC framework.

I agree that OS’s and web standards are becoming less and less user serving, and more corporate/attention economy serving.

I wouldn’t be shocked to see the web bifurcate eventually, between HTTP/HTML/JS and something simpler served over a simpler protocol.

That being said, I do think there’s some value in having an opinionated author compelling people to conform to their standard. When that leadership is absent, you end up with something like the Bluetooth or USB standard, and everybody suffers.

But at least those standards will exist forever, until they’re superseded by something that’s a superset of them. The same can’t be reliably said about the F/OSS we’ve been talking about.

It’s all a series of trade offs. I’m not too pessimistic. I think we’ll eventually end up in a better place, but we will likely stub our toes and bump our head am any times on the way there.

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

#334

Post by ghaff » Thu, Jan 07, 2021, 3:12 PM UTC

astrange wrote: post #276

wolco2 wrote: post #274

Earlier quoted context omitted.

Having a tech track is the right direction. Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.

I think that would encourage not getting raises. You need some kind of title so people can feel responsible for career growth and so you can calibrate against other companies' pay at least; it doesn't need to control what kind of work you're allowed to do.

Even if they don't transition to managing people, someone in an individual contributor role presumably needs to be growing in some way if they want to get raises. While someone doing something valuable even without growing will probably continue to get small raises anyway, it's not the ideal path.

And, as you say, to the degree that position titles mean something cross-company, it gives a point of comparison.

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

#335

Post by rnd33 » Thu, Jan 07, 2021, 3:25 PM UTC

nicoburns wrote: post #44

peterangular wrote: post #35

Earlier quoted context omitted.

> My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. I'm growing further and further away from this mentality in hiring because the sad truth is most of those folks who come in with "quirks" lack maturity. To me, quirks…

> not dressing appropriately for an interview What is "dressing appropriately". I wore a suit to my very first interview for a dev position and very nearly didn't get the job because they were worried I wouldn't fit in (luckily I was able to explain that I don't usually wear a suit). The other ones in your list, sure. But I don't think those are what people typically means when they talk about quirks.

Dressing appropriately does not mean "dressing up". It means dressing slightly above what is generally accepted as the normal dress code for the role your interviewing for, and the culture of the company. This is what makes it so hard, if it was just about putting a suit on everyone could do it.

If you're completely unsure, just call the hiring manager and ask. "What's the dress code at company X?", "How do people in role X normally dress at your company?". No one will be mad at you for making an effort and trying fit into the culture.

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

#336

Post by yowlingcat » Thu, Jan 07, 2021, 3:39 PM UTC

Dirlewanger wrote: post #324

KineticLensman wrote: post #51

Earlier quoted context omitted.

Agree. One of the most important skills is the one he describes like this: >> The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated. In my experience (35 years), this isn't just about knowing the right way to describe things, it's also understanding what things to concentrate on when communicating, and what to ignore. If you are a tech pers…

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 during that era of my life just by sheer osmosis.

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

#337

Post by matthias509 » Thu, Jan 07, 2021, 3:46 PM UTC

fairity wrote: post #288

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…

> The more of these things you do, you become orders of magnitude more impactful than a pure coder. Your job satisfaction/pay are also a function of how unique your skillset is. With this in mind, increasing your impact (through soft skills) is just one of two ways to increase pay - the other way is to do something that not many others can do. For many people, doing something unique is far more satisfying than dealin…

> For many people, doing something unique is far more satisfying than dealing with people problems.

These are not mutually exclusive. If you want to accomplish big unique things, you can't do it yourself. You are going to have to convince others that your big new idea is worth doing so that they will help you achieve it.

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

#338

Post by horsawlarway » Thu, Jan 07, 2021, 4:30 PM UTC

nahname wrote: post #329

horsawlarway wrote: post #253

Earlier quoted context omitted.

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

That's too bad. I worked at a dotnet shop when I learned rails (on my own) and it was night and day for me. ASP.NET is a poor framework that was tries to take the windows decktop app experience and port it to web. Turns out that is a bad idea... Which frameworks do you recommend today?

Depends on what I'm trying to do.

If I'm building an API for clients - I've really been enjoying Typescript and plain old Express. Setup takes an extra 30 minutes or so compared to Rails - probably longer if you aren't familiar with Typescript and Node already - but it works nicely, has a great minimal default, and mostly gets out of the way. Big plus is that type information can be shared across the client and the server, so you avoid a lot of duplicate effort redefining types, and you don't accidentally change a type on the client and forget the server, or vice versa.

If I'm doing something experimental or hacky (last time I was creating a MITM proxy) definitely GoLang. The language is slim and powerful, they let you peel back most of the abstractions as needed, and the code is fast. The downside is it will absolutely take you longer to get running. The upside is a lack of hurdles once you're actually moving.

If I'm just spinning up a simple static/mostly static site - I actually think DotNet Core is a decent framework. Honestly, so is Rails in this case. I'd pick C# over ruby in a heartbeat, though, explicitly because the older I get, the more I want a type system.

Honestly, I think Rails (and really Ruby) is moving in a direction I support. Particularly adding types. But it's not a language/framework I would pick at the moment, unless I was just doing one-time contract work for a product I know won't be updated.

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

#339

Post by The_Colonel » Thu, Jan 07, 2021, 4:38 PM UTC

marcus_holmes wrote: post #317

Tainnor wrote: post #315

Earlier quoted context omitted.

> But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to…

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 typical corporate IT landscape), then it becomes way more complex on all fronts. (Enterprise) architecture is also interfacing heavily with business decisions and company structure. You need to think a lot about how your ivory tower architecture will be actually used by the teams.

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

#340

Post by nicoburns » Thu, Jan 07, 2021, 5:34 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…

> you can't be bothered to dress semi-professionally

It seems to me that you're making an assumption about what is considered professional dress. I feel like it's fine to have such expectations, but you should express them clearly in the invitation to interview. It's not a case of "not bothering" if you have never expressed that preference in the first place.