What we don't teach or reward today is the behaviors and engineering process to write high quality code.
A surprising number of inexperienced developers do the following: "once I get any working solution I should immediately open a PR" and let the senior engineers tell them what's wrong with it.
When the big money leaves this field I hope there will be more pressure for people to adopt good engineering practices. I love to work with folks who put good effort into trying to make high quality changes. Personal initiative and ethics are how high quality software gets written.
Agreed, this has been one of the habits I've had to break during my computer engineering PhD at a scientific research lab. Initially I was just submitting the first solution I came up with without much additional thought.
My senior developer mentors ended up having to effectively rewrite all of it because while it was technically correct and efficient, it broke all sorts of other good practices (eg didn't fit the existing coding style), or added in additional library dependencies without much thought towards long term maintainability and backwards compatibility.
It was taking so much time for the handful of already busy developers to go through my work that I had to learn to slow down, properly study the existing code and think about writing high quality code that fits the existing codebase. They didn't have the time to put down all their other work just to spend hours walking me through improving.
As you mention, it was like with learning art, it's impractical for a teacher to walk you through everything, you have to learn to identify errors and things you need to improve through your own meticulous study, relying on the teacher to give you hints when you're stuck.
You’re right and it’s even worse. Much of the content on “engineering” especially on YouTube teaches resource intensive and overly complex practices sold as good programming. Moving more work to runtime. Increasing dependencies. Relying increasingly on blocking RPC. Wasting memory, cpu and storage.
A rejection of performance and compatibility as the core principles of software engineering in favor of “syntactic sugar” and “idiomatic Haskell”
> folks who put good effort into trying to make high quality changes.
In my 13 years in the industry, I’ve never worked at a place that valued that. More features faster, how many points this sprint is all that mattered. It’s put me off software engineering altogether.
The process you're describing is the exact thing you want to happen: junior developers are trying to learn to write better code. Why should they waste their time researching not their code base when they can instead learn off their code base from people experienced with it?
Because that's what everyone does? You learn by studying other's people work and try to apply it to your own. Painters, musicians, architects, etc … all do it. Why not developers? Instead everyone's rushing to learn React without even knowing the DOM api. Or build a web app with 1000s of dependencies that could be done with a few PHP files. And then they say they need docker and k8s.
The entire debate is over which qualities count as "better". Even "readable" is subjective. Some people love Java with sentence-long variable names. Some love 1-letter vars. Some love 100-deep call stacks, some love flat code. Some love microservices, some love resident call-stacks.
This is essentially true. Pharma is incredibly expensive (for lots of different reasons), with R&D taking up a huge portion of those costs.
So yes, it's safe to assume that part of the accounting around those published costs in the billions are all of the failed candidates that never even made it to trials (the failure rate varies depending on the area of biology and the type of drug, but it's generally around 9 out of every 10 candidates [1]. By the time you get to trials, that ratio gets even more abysmal).
Disclaimer -- I work for Recursion, a company built around this very problem.
R&D takes lots, but so does compliance --for good reason. But compliance costs a lot of money, directly and indirectly. Lots of people, lots of inefficient processes, etc.
And also for failed executive pay, and failed lobbying, which are much more expensive. In some cases (like Aduhelm) the marketing started before it was shown to have efficacy... so you have to pay for that very expensive failure too.
Wow! What do you work on? Is the problem the ability of the candidates -- do you think it's possible for a "good" engineer to get productive on six months?
There also used to be Triplebyte. It filled a niche of talented people who have bad resumes and don't know anybody. Found a great job through them when I was starting out.
Real shame there's nothing to replace it, there's huge arbitrage in the market of good people who don't know people. If I were starting out now I don't know what I would do, how do you even meet people.
They did tons of open tech interviews for basically anyone who could pass an online quiz, and if they thought they found a good candidate Triplebyte would provide them as higher quality / prescreened candidates to other tech companies looking to make a hire (for a recruiting fee).
I got my first job through Triplebyte actually. I think I would have gotten one without it since I was getting interviews and getting better at them. Even though I had passed the Triplebyte tech screen I got very few company "matches" or opportunities through them, but one ended up working out for me to get my foot in the door.
Is there more of that type of content? Or is it pushed up by the tiktok algorithm more than other social media? I don't think this is the case, but you are not in a position to state that categorically.
I don't think you'll ever be able to get a straight & correct answer to that question, but I don't think it really matters, because the effect is the same.
I and every friend I've talked to about tiktok has seen much more political content on tiktok than other short video apps.
You don’t think it matters whether you are viewing the authentic crowdsourced views of your countrymen, or the boosted political propaganda of an adversary?
There is an excellent old book on the subject, How to Win Friends and Influence People. I was lacking in this area and my career improved greatly after reading it.
In general, people are cautious when giving criticism because it carries implications.
Say a manager gives negative feedback to a subordinate. The subordinate now believes the manager doesn't like them. The subordinate follows the standard advice: start looking for another job. Manager now has the larger problem of hiring a replacement.
It's best to reinforce positive behavior. Little trick I learned: compliment people. Find an reason to say "nice work" on every code review. DM people and say "nice presentation", "great design". It works.
> There is an excellent old book on the subject, How to Win Friends and Influence People. I was lacking in this area and my career improved greatly after reading it.
I've read the book, as a matter of fact. :) Although it's been quite a few years, I recall feeling like it was mostly a guide on manipulating people, and it didn't make a great impression on me, personally. I'm glad it was helpful for you, though!
> Say a manager gives negative feedback to a subordinate. The subordinate now believes the manager doesn't like them.
I hear this and think back to what I said in my previous comment about the value of their feedback. There are certainly things a manager could say that would leave me feeling disliked in a personal way, but I can easily separate genuine feedback about my work or my ideas from personal statements.
> It's best to reinforce positive behavior. Little trick I learned: compliment people. Find an reason to say "nice work" on every code review. DM people and say "nice presentation", "great design". It works.
I, too, believe in the value of giving genuine compliments, and I try to make sure I tell people any time I think they are doing good work. A clever solution deserves acknowledgement, for example. I suppose it just doesn't feel genuine when I'm using them to soften the potential blow of constructive criticism.
A surprising number of inexperienced developers do the following: "once I get any working solution I should immediately open a PR" and let the senior engineers tell them what's wrong with it.
When the big money leaves this field I hope there will be more pressure for people to adopt good engineering practices. I love to work with folks who put good effort into trying to make high quality changes. Personal initiative and ethics are how high quality software gets written.