As for attributing burnout as the core issue here, I would strongly disagree with this idea. When teaching undergrads I noticed immediately that a good portion of each student cohort was basically there because they were interested in making money in the future rather than exploring the ideas of computer science. They were no doubt going to get frustrated or bored and move into management or some other profession rather than continue to expand as an engineer. This is totally fine, and they are probably richer for having learned what they did, but I don't know why we can't just see this and appreciate it for what it is rather than portraying it as the drama of burnout.

The entire industry focuses way too much on 'experience with tool X' as a proxy for 'technical skill Y'. It's a bit like asking a carpenter how many years of experience they have with DeWalt cordless nail guns rather than ask about their house framing skills.

When we recruit we ask "if we tell you no more Spring and we'll work on any language as long as there's a problem to solve, how do you feel". Most either say they d feel horribly sad, or dont even comprehend how it's possible. Some are indifferent because they need the job. Still looking for the guy that says "anything can be learned in a reasonable amount of time" so it s not that obvious I suppose :(

What I think is missing is there are serious diminishing returns with more experience in a specific language or framework. 10 years of experience split 3 in Java and 7 in C# is very similar to 7 in Java and 3 in C#.

Maybe the base "lawyering" or "nursing" does change but they'll have seen a lot more examples and be able to pattern match quicker.

Also I'd rather a 20 year nurse was the Charge Nurse rather than a 5 or 10 year one, I'd expect they'd know more how to lead others (although time served isn't always an indicator of a good leader).

They've also been burned out by being 20 years in the field. Motivation is a very very crucial thing for success and motivation often times declines due to burnout. Yes said lawyer saw more cases as mine than his younger colleague but he might not be super motivated to fight for me in court as he was 20 years ago, and in any case there are constant tiny changes to laws that make the 20 years experience worth less.

Btw I think 55 year old lawyers/accountants who look for a job face pretty much the same discrimination as software developers - they are expected to be director level or there's not that many jobs for them. This thing is definitely not unique to our profession...ageism is a thing everywhere.

It's what I do at work for fun, in between my "real" development / support tasks. I profile and optimize our internal application, its loading time, user interactions, etc.

Sometimes when it's a long term I make a proof of concept and ask for permissions later, so for a while optimization becomes my actual job. Just finished a couple of months of performance tuning, actually, which I did in parallel to other tasks.

TBH there are plenty of easy, low hanging fruits since the team who wrote it wouldn't recognize a performant code if it smacked them in the face. Or they concentrated on very minor optimizations in rarely executed parts of the code and tended to bikeshed them for hours instead of actually checking what the real problems were.

I actually almost never use an actual profiler when starting, I just run under the debugger and pause the application at random instances when it appears to be stuck.

In almost all cases I find it's executing some unnecessary batch of queries, or reading from a table using an unindexed column, or redrawing parts of the screen which shouldn't be updated, or throwing and catching exceptions that were used instead of if statements, or blocked when it could run in parallel to some other computation, or doing some other unnecessary O(n^2) loops instead of using a hash table. A combination of such improvements will sometimes gain up to 20%-40% speed or even more.

When I'm done with these simple cases I start using a profiler for the that extra optimizations for those extra percentages.

I can definitely see why some people might hate that situation, because it feels like nothing is working and you dont know anything at first. But if you aren't demoralized by that, and instead find joy in learning/figuring out all those new things on a regular basis, it all feels extremely rewarding. Like, why would I dislike being paid to essentially learn a bunch of new stuff regularly and solve actual real world impact problems using that new knowledge.

I learned so much in that job, and probably would have kept it had they not relocated it to Santa Clara.

If you can work in an environment like this for a few years you definitely should, that's my advice to everyone. You'll learn so many things that will be useful over the rest of your career.

But most software aren't the linux kernel, they're small systems solving a class of specific problems as fast as possible with rotating teams, so it sometimes is just a matter of profiling this stupid hashcode function or asking why the mouse is freezing during high trading volume on the C# GUI :D

You wouldnt believe how common optimization problems are and are not related to GC, a belief I have to disprove very often (look 300ms of GC a day, but hey, you're checking an unindexed table each calculation for a trivial non essential decision, what if we fix it)

[1] https://news.ycombinator.com/item?id=26296339

[1] https://use-the-index-luke.com/3-minute-test

Beyond that, it's just making sure you do less stuff, and being really aggressive with profiling (what looks like it takes the most time in the code almost certainly isn't what's really taking the most time).

I routinely say something to this affect in jobs for which I a interviewing. I tell them I am not an expert in anything, but I feel I can learn anything given enough time. The caveat is in some businesses time is the limiting factor and the business doesn't have the time for me to learn.

But I'd love to work for your company or one like it.

k8s surfaced and I tried to learn about it, but it's just too complicated. After I had spent 2 weeks of intensive mind bashing at it, I still wasn't able to manually set up a 3 node initial control cluster. I gave up on it, never looked back.

Spring boot time and again, medium difficulty picking up, mostly because of the exclusive Java community, if something like that even exists. Very arrogant bunch that speaks in implicit ways and assumes you just magically know stuff.

Android is similar, always in flux, despite the many resources offered by Google you don't know what to pick. New Jetpack compose or old, ancient seeming xml layouts and configuration and navigation configuration. It's a hot mess. I tried to use AppAuth OIDC client, has a few questions, asked, the response was "We assume some prior Java and Android knowledge". Well, ok thanks for nothing.

Angular, aside from rxjs, which was royal pain in the ass to learn, straightforward, albeit a bit overly complicated and typescript gets in the way more than it should.

Jumped to Vue. Oh dear god, it's so nice and easy. None of the rxjs stupidity, no forced typescript and a large ecosystem. I can be super productive with it and create SPA, PWA, SSR, Electron apps, browser plugins, even hybrid mobile apps with it.

Rust, my arch enemy. I tried to get into it, I was drawn by hype and the promise of more performance. But knowing Go, which is just good enough for the backend, and where things make sense, Rust doesn't make sense for me. For someone coming from C++ it must seem like the 2nd coming of Jesus, for me - the Go guy - it's an abomination. Yeah I get the basics, but imports don't make any sense, structure doesn't make any sense, erorrs don't make any sense. I feel like a freaking transporter always worrying about crates and boxes and who they belong to. Not fun at all. Handle with care, careful breakable. UGH.

Yeah anything can be picked up but it depends on me being interested in what's to be picked up, the willingness of others to teach and the justification of why I need this added complexity.

I write monoliths and I'm happy with that. Now all jobs postings require Microservices and EDA. I'm unhappy with that because I don't see the need for it in most cases. Now I have to learn expensive cloud on my own, which I have ZERO motivation for. I have to make everything extra complicated, it's hard enough as is getting a project done start to finish, client and server, the monolith way. If I'd have to go Microservices I'd never finish anything and even if, when launching until people actually use my service, 3 years later I'd be bancrupt. So where am I supposed to learn about this unless employed by those people who want Microservice EDA? But they won't employ me because I have no experience with that.

Because if the garbage collector is the bottleneck you need to fix your code to not produce so much garbage.

The code had some sizable chunks of JavaScript in Strings and looked at each authorization the user had. Its been awhile, but in dynamically generating that JavaScript (ICK!) it generated several megabytes of garbage Strings by doing `script = script + "little bit more";` way too many times. This was done for each page load. 8am and hundreds of people click the page to get their start of day stuff... and... server has problems.

That particular issue was fixed by changing it all to a StringBuilder.

I've yet to see any sloppy garbage creating that is on the same order of magnitude as that JSP was.

    String foo = "foo";
    foo += "bar";

    String foo = "foo";
    foo = new StringBuilder(foo).append("bar");

    String foo = "foo";
    foo += "bar";
    foo += "qux";

    String foo = "foo";
    foo = new StringBuilder(foo).append("bar");
    foo = new StringBuilder(foo).append("qux");

The actual code was more complicated (and bigger strings), but the issue is that each statement is its own StringBuilder.

That prompted me to explore it and I looked at the byte code invocations at http://shagie.net/2014/08/17/what-goes-on-behind-the-scenes-...

To me that's noise and not much else.

Something I don't think a lot of folks realize is that there's two parallel industries (and pipelines to jobs in the industry). They almost never overlap.

One in which recruiting is largely done by non-technical folks who match keywords of frameworks, and where rote and learning whatever library is seen as the objective (bootcamps come to mind).

The other one where CS fundamentals are seen as the priority, and where hiring focusses on finding people who posses the skill of acquiring new knowledge.

You can guess in which one Google and FAANG or whatever the acronym is now and Stanford/MIT exists.

We routinely have & hire interns from top programs and many lesser known ones, or even non-CS degree holders.

Small aside. It describes Google and Facebook and the others several years ago. Speaking anecdotally, the impressive people at those firms are fewer and farther in between.

One of the key things that self taught developers miss is the instruction and review of the code. You write code differently if you're going to be graded or if its a throw away script.

In theory, job code that is going to last for more than a run should be written closer to the rigor of the graded code while people who have self taught have never had their code reviewed in their instructional period and tend to (not always, but tend to) write code that wouldn't stand up as well to review.

There are plenty of graduates who don't write code that stands up to review either... but there is a "you have spent a few hundred hours writing code and had it graded, and changed how you write code to get a better grade."

For a person who comes into a CS degree program without experience at coding, and they do their homework, I tend to believe that they will have code that stands up better to review and fewer bad habits than someone who followed a self taught progression.

The quality of reviewable code from a cs student is not surprisingly not great but languages like python force some standards.

Neither prepare a student like a community college. Usually the most successful group in the job market.

This kind of logic only works for tech organizations that already have enough in-house domain expertise to onboard new programmers. The other day somebody asked me how to find a programmer to implement something for them. From a programming standpoint there was very little to do, but it involved many obscure technologies that you couldn't pickup in a day (and no you can't pick different technologies). For a person who's already done something similar it'd be a quick and easy job, shouldn't cost too much. With a generic programmer it'd take much longer, cost much more and you couldn't be sure they'd actually deliver.

It is even harder if you don't even know how to verify that person really is experienced with specific tool set.

So it goes like "pick your poison", hire generic dev and account for learning curve or spend money on recruiting fees/time for finding an expert. Where I would not be so quick to say "expert shouldn't cost too much" - because I can imagine expert taking less time but costing orders of magnitude more than generic dev.

Strongly emphasizing this. This is HIGHY applicable to the analytics environment. As a business analyst who specialized in mostly ad-hoc development because it was the most value-add area at the companies I worked with.. I had a lot of trouble finding new work because I didnt use Tableau, or Power BI, or Looker, etc. I was some sort of fool for doing everything in SQL, Excel, and Python.

IMO the tools are great, and you need a much lower level understanding of analytical concepts to get value from them. But for some reason people kept getting the impression I would somehow be less effective with them because I dont use them. And I had trouble correcting them with the limited bandwidth that exists to communicate with a single applicant in the hiring process. If I tried to get right to the point, I felt myself appearing arrogant.

The carpentry analogy is very similar to how i described it. "I am currently using a ruler and screwdriver, and these tools provide lasers and power drills"

Give them six+ months to train up and I’m sure they’ll do fine.

They tend to bike-shed details, take way too long to try to create sophisticated abstractions that never quite achieve the silver bullet they originally thought it would, and spend too much time dwelling on irrelevant details that ultimately leads no where and results in a kind of paralysis that can be very hard to break out from.

The ones who master a specific language or master a specific library/technology that focuses on doing a few things very well and in very concrete terms are able to deliver the most business value. Furthermore they absolutely have the ability to take their mastery of that and map it to new languages or new libraries. I mean I'm not talking about going from Java to Haskell or Haskell to Idris, but rather people who master C++ can fairly easily pick up Java or Python or TypeScript. People who have mastered Unity can easily pick up Unreal Engine. People who have mastered web development can easily pick up mobile development.

The idea that people who have a solid mastery of a technology and a programming language are somehow just stuck and unable to take those skills and apply them to other areas I think is overstated and just untrue, but those who treat software engineering as highly theoretical and focus on abstractions, design principles and get caught up on these high level details tend to not get much done and when they realize that software is not as clean and elegant as they would like it to be, they get burned out and give up.

I think going over any substantial codebase for products that are widely used and deliver solid business value on Github where most code is not at all reflective of the ideals often espoused on blog posts validates my point of view.

In short, people who treat software as just a tool to accomplish a concrete task are more productive than those who write software for the sake of writing software. They don't write the cleanest code, or the most elegant data structures and algorithms, but they produce the greatest amount of tangible business value.

> "meta-level" concepts

I'd say having a strong grasp of what you can achieve with just using files and folder, or understanding how SQL solves en entire problem space are meta level concepts. Its just that we take them for granted.

> business value

Is apparently something different than 'value', but still includes every software ever that was valuable to a business?

> high level details

...?

> software engineering

Building constraint solver for a compiler or ensuring a JS animation centers a div?

> highly theoretical and focus on abstractions, design principles

I'd recognize all these things. But out of context 'in the general case' they become meaningless.

---

I understand the picture you are trying to paint, but i don't think it tells anything beyond "I've noticed people make things overly complex". I agree.

However, keep in mind the 'get things done and provides value' software you've seen: is the software 'that survived', might have been set up by a very experienced person ( whose failures we're not seeing ), nobody might recognize it as being not-simple ( e.g. I've seen high value business software partial recreate 'regex'. Worked great, straightforward and easy to read function, just ~50 lines or so, could have been a single function call. ), how the requirements are presented is hugely important.

There is a lot of people who learn just a surface without going deep into tool and think they know enough.

For me it seems that someone who would really go deep into learning language would get most of theoretical stuff on the way. Because there is no way to really master C++ or really master Java without learning about data structures and all kinds of "meta-level" concepts.

Maybe the difference is mostly approach to learning more practical/more theoretical.

Some guys see a screw and reach for their trusty hammer. Some guys know to grab a screwdriver.

I had a project the last two weeks where the code was just going to fail about as often as it was going to succeed. I had to write a resource manager and an Erlang style supervisor and use an embedded key value store.

A better dev may have intuited what took me basically a midstream rewrite to figure out, a worse developer may still be grinding on the problem.

I think my solve is "robust enough" but there was no real way to power through that. You either found the right abstractions or you didn't.

And as music goes, you sound like the record companies that thought everyone should listen to disco for the next 50 years...

Now give me a new theoretical concept where I can expand my knowledge or integrate into my knowledge map and view of the world and I'm excited, there aren't enough hours in the day. Tell me about this all new concept I wasn't familiar with--I'll start thinking of ways I can use it, how I can leverage it, or how it may connect with other ideas and concepts I have.

Now give me a tight deadline which most business environments create and I agree with you, give me the boring stuff I can pump out, get my paycheck and go home to enjoy the rest of my day.

The article showed the opposite effect though. Curious, life-long learners stop working in software development because they have to constantly learn new skills and believe they can get more bang for their buck when they can invest in skills that don’t lose their value over time.

After six months of this, ExtJS 4 came out, which was essentially a totally new framework. Everything I learned was not only not applicable, it had to be actively unlearned.

The lesson here is: become good and proficient at something, but don't focus on becoming a ninja in one particular transient tech. There is value in becoming a Jedi of Unix build-in tools, or more persistent technologies like Git, for example.

Also, this is a bigger problem in the Javascript echosystem, where the hype cycles are more intense than in, say, Python. I checked out my Flask project from seven years ago and it's ready to rock.

I get the thing about constant learning, but learning in this industry used to be cumulative. Now it's a hamster wheel. You are learning how to solve the same problems, in a different, presumably in a "new" way.

People seem to be spending more time coming up with catchy names for their projects than making sure this is all sustainable.

The only skills that have really stood the test of time for me are C, PHP, unix shell stuff, and SQL.

The truth is that the programmers in group (b) think about both. Who's designing a lot of the new languages, libraries, and frameworks? Chances are it was someone from group (a). If you're in group (b) then do you want to spend your whole career being forced by your bosses to constantly relearn and follow the latest vogue vision from group (a)? Of course not. So this might not apply to students, but everyone from group (b) will eventually get burned by fads enough times that they start caring about the politics of software. Namely, not wanting to depend on bloat that doesn't actually solve computer science and systems engineering problems. Group (b) might even create alternatives themselves. Go is great example. The guys who built the Fifth Bell System watched their vision behind their techniques decline over the decades and said, enough is enough. So they made Go and it was like a ray of sunshine when it came out.

However, these still don't invalidate the main point of the article, that a faster rate depreciation means that your max knowledge level, given your specific rate of learning, will be lower. I.e. your advantage over a less skilled, younger professional will be lower.

And you may say that learning a new 3D library shouldn't be counted as learning a new skill, but it doesn't make the problem go away. If anything, it underlines it: if you have to start working with a new 3D library then you will have to spend time and effort on learning it (to become efficient at using it) while if you were able to keep using it, you could spend that time and effort on learning something that we could count as a new skill.

- A younger engineer will have the same value to your employer as you do.

- A younger engineer will work harder than you are willing to.

These two items are inevitable given the current rate of change in the industry. While some engineers will find next level differentiated work to engage in such as leading a core piece of infrastructure which defines the changing field... Many will not. If the rug gets pulled on this core piece of infrastructure.. then it's often the case that the engineers are not particularly more skilled than others on brand new projects.

In my school, those who wanted to make money went straight to management or finance. Computer science was for the passionate ones and probably not the right path to make money for the brightest students.

well so do the recruiters, they’ll be fine

in fact, the better students are the ones wasting their time unless they prefer to be in academia, like you

so what metric are you really gauging for?

the “poor students” are pivoting for money and the name of the university to boost their employment prospects, maybe this shows in their academic performance and ability to understand, I saw the same in undergrad

Not true. I have met many developers who haven't learned anything new for 15+ years and are still doing just fine developing software. A lot of Java developers come to mind. They have pretty much done the same thing their whole career and have no need or desire to learn anything new.

I think many teams are unaware how much extra value is possible by retaining existing employees vs hiring new ones. Each year I'd try to make sure I was "making them an offer they couldn't refuse" with new interesting challenges, new tech, plenty of personal research time, as much pay increase as I could possibly give, etc. A lot of engineering managers think that it's no big deal to just hire new staff, but even going from average turnover of two years to three years is an massive improvement.

The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of code. Everything has to have some immediate business impact. I even see scrum teams measuring for team utilization now. target is 90% atm and they wonder why productivity is down.

The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out.

I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels.

So I respond by easing up on advancing my career, because it gives back to me the least.

I always wondered why people complained about how much time certain aspects took up they could automate away and my question was always: well, once you automate away that nice simple task, what do you do with the extra time? You created more slack and someone's going to come looking to fill that void the second they're aware. And the new task is going to be more difficult until you get to sets of tasks so cognitively intense and complex you can't simply automate them away. Then your day is filled with incredibly challenging stressful work.

I have no issue with doing complex work, I've spent my career doing it. What I have issue with is the amount of such work I can do in any given time span. At some point I need a break where I do something simple and mundane. Continous complex problem solving is the road to burnout. You'll be greeted by more and more failure and lack of visible progress combined with ever increasing stress levels.

If you're an entrepreneur, small business owner, or manager looking to optimize your labor force then you may want the opposite. You want more time to focus on the complex and the more simple you can automate, the better or if you have a workforce, you want your highest comped individuals focusing on the most optimally complex tasks they're capable of handling. You don't want your Fellow level engineer refilling the coffee maker because it's empty or implementing some basic features on some UI, go back to inventing new algorithms, math, or building new technology... but people need those nice relaxing breaks and slack, they can't run at their best constantly.

I can easily imagine how it goes - because pushing tickets over takes time, bunch of meetings during the day takes time, explaining stuff to junior devs takes time, reviewing pull requests and answering to comments takes time, clarifying things with QA/BA/PO, figuring out which libraries to use by googling takes time.

I saw devs that think these things that I have listed don't feel like "real work" but it is. There is also no way to automate meetings or discussions over PRs.

Software Engineers will still be pulling 100k+ in Europe with those 2 hour days.

There's a book to hunt up...

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

It's written by Tom DeMarco of Peopleware fame.

It's heartbreaking how much human suffering is entirely avoidable in a post scarcity society where it is still artificially enforced to avoid the "moral hazard" of commoners daring not to toil or worry every waking hour

So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO.

Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.

I've found compliance makes it harder to write good code. If you get a PR approval with optional suggestions you're heavily disincentivised from actually addressing those comments since if you push those changes you now need to wait for review again.

Like everything process and compliance it's designed by low-confidence managers with an inate distrust of their teams.

In our product, a change has the potential to cost businesses lots of money and also bring our customers into legal trouble, potentially making us liable too.

That's why we have heavy-handed change control, code vetting and so on. Yes it makes things slower, but due to the risks involved.

I've also worked on embedded projects where field updates are HARD and costly. We had heavy-handed change control then.

When I put those controls/processes in place, it wasn't due to low confidence, it was due to confidence in two things: (a) even the best SWE makes mistakes and (b) work to control change risk pays off

Sure, it isn't appropriate in many chases, but to write-off process as being designed by "low-confidence managers" because you don't see the point, is a bit myopic.

Any SWE who thinks that a codebase doesn't benefit from review before merging is driving on ego.

> Sure, it isn't appropriate in many cases

I think where low-confidence management comes in is the application of the process without reference to whether the process is appropriate. It's easier to require all changes to be reviewed, every change to have a ticket and all post-approval changes to require re-approval even if the thing being edited is CSS for an internal tool than it is to build out process that accounts for the field and risk.

It feels like many places/management teams take an "off-the-shelf" compliance approach rather than constructing a process that works for the team.

New management took over (they finally realized they bought us out a few years ago), shoving "Agile" down our throats, we've missed multiple deadlines, every deployment has been a disaster, and there are still outstanding bugs that won't be fixed Any Time Soon because they're not on the release schedule.

Oh, and the new mandatory code reviews before checking in code hasn't helped since bugs still got through (and I've lost code because it wasn't checked in---it's not helping matters that we're still stuck on SVN, and half the team can't access the master SVN server).

Yeah, the overhead sure is doing great for us.

Edit: fixed typo.

Read the underlying compliance requirements carefully. In the case of e.g. SOC2, the regulation requires visibility but does not say who may open tickets or who needs to approve them. You can do a lot by making processes more open, and so long as they are still visible, you can still pass.

If specific customers tell you how to run your business, either write process that isolates their requirements to a bare corner of the business (e.g. a completely separate environment for FedRAMP) or consider firing those customers.

Unless company does not want to have any devs working on that project in the future. But it would be just like not wanting customers to use that project.

If your PO is sensible then a couple of paragraphs explaining why refactoring is important with a closing line that says spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time. People aren't stupid. Once they understand why something is necessary they've very receptive.

Also, add refactoring time in to your estimates in the future and you won't end up in this situation, plus the code that's committed will be better.

One of my friends is a technical writer and she is amazed we put up with this on the engineering side. No one would ask it of other professionals.

From my experience, this is more a cop-out than anything else. At some point I'd expect you understand children with a track record of doing as they are told and informing you of important details do not need to be strictly parented around every corner. To expect that very thing from adults with way bigger incentives to behave feels off.

What looks like a small change to a developer is never actually a small change.

I really hope there aren't that many people impacted when you go for a piss.

Not every change affect other people, but isn't that my call to decide? Also "simple" in quotes implies it isn't i.e. you aren't trusting what you are told.

> What looks like a small change to a developer is never actually a small change.

Not true, this is hyperbole. If the lawyers need to be consulted to change dependencies this is something a developer should know and account for. Why keep devs out of the loop?

I consult with other devs, QAs (if needed) & external teams, perhaps with a ticket if deemed necessary, other times just a PR. I run the (CI) regression, I schedule/announce and perform deployment (we have platform team, not "devops" which is generally done by the app devs), I write the app docs, we have no legal documentation that lists the licenses for the dependencies.

I do this as a dev - why should I not be able to recognise if a change is small or not? let alone never being able to.

In my experience that’s very rarely if ever the case. Managers will always favor features over fixes in the kind of company that ends up with a crippling tech debt problem. They got there by not listening to engineers and having salesmen managers. These companies never change and no manager wants to be the one who’s fixing things for the next manager after they get promoted. People are idiots (maybe) but they respond to incentives. And very often the incentive is that problems that may arise in a year or two are someone else’s problems so not worth fixing now.

Exactly the same where I work. The pace of getting things done is absolutely glacial compared to what you know you could achieve if you had any agency. I think the only reason this organization I'm temporarily a part of can even compete is that all its competitors must be equally inefficient.

I wouldn't want to be accountable in that situation.

Every change carries risk.

You can do the change work in a feature branch and propose the idea after the fact. If there's interest "I've already done it." Stakeholders get a bit of instant gratification like their request just materialized into thin air. If they're not interested, don't mention it and let the work go unused, rack it up as professional development time and work.

I do this fairly often. If a decision has a bunch of real risk associated with it I make sure to get sign off and create an appropriate evidence trail to pass risk back up when it's passed down. Much of work is just passing risk and liability around to PYA.

I'm not sure I'd keep someone on the team who did a branch AWOL and proposed the idea after the fact. Doesn't show much respect for the team, that time could've been spent working towards goals agreed by the whole team.

If you don't have a lead or management environment with ears open to exploratory change, tech debt payoff or "do it better" tasks or whatever... and you have to manage up so much... that sounds like an issue to me.

There's also an assumption buried in there that any time spent working is somehow owned by you, your leadership, or the organization and not your team or teammates time. I've personally spent plenty of hours "off the clock" investing in directions I think are correct in an IC environment and it's paid off many times (I've also wasted my time on occasion but it's my own time and my choice). If you have slack in your schedule or want to push something out by taking initiative, then the type of management philosophy describe loathes initiative, creativity, and innovation in engineering. It's a great way to drive those abilities out of your teams and organizations.

It's good to foster teamwork and target goals but you also have to give your teams some degree of autonomy, otherwise just as the article describes, they will leave from the drudgery. The allure of technology is the tangibility of innovation. If you rip that off development, for many, the work becomes unenjoyable, tedious, repetitive, etc.

What issue? My projects are delivered on time, on budget and to the customers expectations without undue risk or unpredictability. That's my job.

Nobody on my teams would say I micromanage them, everyone has a large degree of autonomy within a framework of shared goals and shared values that keeps efforts working towards cohesive results.

With autonomy comes responsibility to the team, business, customer and every stakeholder ... so yes, i'd consider it AWOL to undertake work that doesn't respect the input of everyone else by getting agreement beforehand.

Perhaps that's b/c you are apparently in a position to get rid of people who "go AWOL" despite maintaining "a large degree of autonomy".

If autonomy is prefixed on "within a framework of shared goals and shared values" then why do you think individuals can't do work based on their own conception of those shared goals/values, rather than requiring signoff first? Autonomy is being able to make (and execute) decisions on your own (possibly based on shared information/value/etc) - requiring signoff is not autonomy, it's merely the ability to participate in decision making.

If you're working for the benefit of the product/team I don't see why you would need to, or have an issue with this.

Strange.

You don't always need a ticket for this, if it applies at all. I'm not unaware of these benefits, but the burden lies with you to demonstrate devs cannot be trusted to be autonomous, or choose the appropriate mode of collaboration.

> getting work approved

Why is this always needed?

> If you're working for the benefit

This is a strawman, you can do this without the overhead.

Who do the approvers seek approval from, for the same reason(s), and who do they seek approval from?

> visible to the whole team

This is what standup / status updates are for. It takes all of a few seconds, no approvals needed.

In regard to refactors, people tend to just squash them into another change they are making. This makes the git log a bit harder to follow at times, but people did this back when we just used to push to trunk too so I don't think the story is the deciding factor.

I would say for non-tech companies with a strict set of IT guidelines, this is mostly true. Please ignore non-tech companies with weak or zero IT culture. It will be the 'Wild West' at those places! Nothing will be maintainable beyond a certain size because there will be so much key person dependency.

For pure tech or tech heavy (banking, insurance, oil & gas, etc.), there is frequently more flexiblity, including "dummy Jiras" just to track a non-QA'able code change like upgrade C++ / DotNet / Java / Python library, or refactor some code. In my experience, 'Jira-per-commit' rule isn't awful, as long as tech debt does not require non-tech approval, and the ticket is just a tracking device. (A few different vendors offer very nice total integration between issue ticket, bug ticket, pull request, code review, etc.) Just a one liner in the Jira should be enough. In my experience, the best teams try hard to "do what works for us", instead of be a slave to the Jira process. Yes, I realise this is highly dependent upon team and corporate culture!

Finally, I would be curious to hear from people who work in embedded programming -- like automotive, aeronautical, other transport, and consumer electronics. I have no experience in those areas, but there is a huge number of embedded programmers in the world! Do you also have a very strict 'Jira-per-commit' rule?

But the actual ticketing/PR system? Change requires control.

The actual issue is not _using_ that control tool to get the right things done. If basic technical debt issues are not an easy sell in your org, that's the real problem and one that should be handled by senior/dev manager.

A big red flag for me is any org that doesn't recognise and service technical debt and empower engineers to make a win.

I also wouldn't say tech debt pay-off should be without its justification in some cases. If an engineer can't measure the positive impact of doing something, it can make it a hard sell. Why should an engineer spend 2 weeks doing something if we can't describe the payoff?

The ticket system isn't for engineers. If it were for the engineers, they wouldn't be continually forced to use it. The ticket system is for the legibility of management or sometimes compliance (other flavors of management). This visibility is at the expense of the productivity of the engineers themselves.

> Change requires control

No, fundamentally, change is gated by control. The more control, the less the change, with sufficient levels of "control" leading to no change.

Of course, in some cases, it is right to say "Here's the problem, and what could go wrong if we don't fix it. You need to accept the risk".

It's a sad fact of life that technical problems need to be sold to non-technical people as they're often the ones shouldering the risk.

Part of my day-to-day is selling tech debt pay-off work to clients who have to pay for it. They rightly ask "why should we pay for this?".

I think in 99% of cases (like your package upgrade example) the systemic failure is elsewhere and the approval is often meaningless and inefficient.

But code, unit tests, git commit messages and merge requests are already providing 4x documentation of code changes. Adding Jira tickets and production deployment documentation gets you to 6x documentation.

In my experience, if your company's problems weren't solved with 4x documentation, they won't be solved by going to 6x documentation.

- Ticket: Description of the requirement

- Code: How it was done

- Review: Peer-learning, change evolution

- Unit test: Testing of implementation as understood by SWE

- QA: Did the change match the requirement, did the SWE understand it? Is the outcome the right one?

Each "item" should serve a distinct purpose, have distinct value and be justified. If they seem like duplicates, then that probably points at issues elsewhere.

- Code change: MAXIMUM_PAGE_SIZE -500 +1000

- Unit test: assert len(request[0:2000]) == 1000

- Commit message: Increase the API maximum page size from 500 to 1000

- Merge request: Increase the API maximum page size from 500 to 1000. For AB-123

- Daily scrum update: I've increased the API maximum page size from 500 to 1000, if someone could have a look at my merge request.

- Deployment request: Increase the API maximum page size from 500 to 1000, for AB-123

- Post-deployment test plan: AB-123, ensure maximum API page size is now 1000

- Stakeholder demo: When an API request is made, the page size is now 1000.

As a reviewer of such a pull request, I'd go over all the places in the code where this page size constant is used.

I'd also like to see a rough assessment of the impact of this change. Does it affect a lot of code? Some code? What percentage of users are to be affected by this change?

Also, who asked for it? It's ok if no user asked for it and it's your own initiative. But if users did ask for it (or rather complained something like "the app rejects our API requests" or "the app is effin slow, please fix"), then it'd be nice to connect to their tickets / mails / chat logs. This could serve as a proof to management if someone decides to question this change.

Deployment: If this change is in an API called by many functions (so, big impact), but it can bring with it a big benefit to many users, I'd like to see a rollout plan - as simple as putting it into a beta version, or (if we have them) using feature flags to enable it, and a plan (can be an automated script) that tracks crashes during this rollout. If the change doesn't have a big impact then that's not necessary.

Ideally I'd like to see coverage results that proves that all those functions which use this constant and all code paths leading to them have coverage. It's perfectly ok if they don't, perfect is the enemy of the good, but at least the major ones. I would also go over carefully at least over some of the code which uses this constant directly and indirectly to ensure no funny business like too many threads allocating this bigger buffer, no funny out of bounds issues due to code assuming size is of a certain length (if it's C/C++/C#) etc.

So really, what is the user-visible impact of this change? If it has no user-visible impact, then why was it made? The ticket as it was specified here doesn't answer this question and therefore reflects a somewhat broken organization/team, where engineers are disconnected from their users and/or lack the eloquence or willingness or time to explain their changes. I bet the person who wrote this doesn't even bother writing comments about non-obvious changes (such as this one!), making their code harder to maintain.

If a developer on our team things something should be done and can do it quickly, they are encouraged to create a ticket and do it. It gets code-reviewed and accepted. If it is not a quick change, they need to bring up the ticket at a planning meeting to make sure it is balanced against other priorities.

Why would I do it? Bit of a rebel I guess.

It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this:

1. Management demands that every bit of work be associated with a ticket

2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system

3. management complains about devs opening "their own" tickets and prohibits self-opened tickets

4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board)

1. management demands that every bit of work be associated with a ticket...

Single line tickets from the CEO that turn into months long projects with no guidance on the functionality. Engineers that burn down entire features because "it's bad code." Secret projects where you get berated for asking stakeholders to to clear up requirements because "you're scaring them."

It's easy to look at a rigid structure and assume it sprang wholecloth from Zeus's head - but most of the time it's an overcorrection. Being burned by a company where Freedom is just an excuse to make employees to work overtime will make anyone go a little overboard.

I hate this. An estimate is an estimate, there is no negotiation, negotiation an estimate is simply interfering with it, making it less objective. It can also be a trick to put pressure on developers.

I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase.

One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a proper refactor.

Once you finish meeting minimum requirements, should you have that margin padding, you can then refine what's been created. Fix issues or shortcuts you may have taken, improve or optimize some portion that'll give significant improvement in experience, add some additional functionality you think would be nice to have where permitted (while the context of everything is fresh in your mind).

Ultimately what's delivered will more often than not meet minimum requirements so whomever requested the work will be satisfied. They may even be incredibly pleased and consider you a wizard for some of the improvements (they also may not want the improvements so be sure to keep those modular you can very easily slice them off if they're undesired).

This keeps everyone happy really. When you start trying to optimize on the estimates so they reach actual time or a little under actual time to pressure developers to do OT, that's when you get into toxic environments. If you give a little error margin developers will likely reinvest it in your application where it sparks joy in them meaning you're about to get the highest quality work, the stuff the engineer wants to do.

Where I work we have 1 'maintenance day' each sprint where the devs choose what to work on. That can be fixing annoying issues, improving the code, learning something, trying something out, etc. It works well when other things aren't taking priority (which is far too often tbh).

Other refactors and systemic expansions, like a slot-based system for advertisement placement, worked a lot better, because I'd learned a little about how to dig into what problems actually existed and how they were causing aggravation to people.

There's got to be a limit to this line of justification though. Lots of people have just plain wrong ideas about 'web development', so catering to their ideas doesn't serve anyone well (except, perhaps, those people, who in the short term don't have to learn anything correctly).

A colleague shares stories of his team who don't grasp the difference between GET and POST, don't understand the term idempotency, believe that 'web dev' testing only means 1 thing, etc. There's... 5 of 6 of them, and only one of him, so... much stuff ends up staying 'wrong', and the 'wrongness' in each section of the code ends up compounding 'wrongness' in other systems/features as they're being added. This matches how this team thinks about web/software development. But it's not in any way beneficial.

The question becomes--where?

This company was incredibly successful up until COVID and is still ticking along, so it's hard to argue. I gather they've done significant work to rebuild the universe in that time, though. I might've just been early.

The problem I hadn't fully understood was a mix of the last point you suggested--tedium's just how it is--and a set of libraries built up as coping mechanisms that were intrinsically tied to the servlets process. Not really written to be able to be shimmed into a better world without dragging the whole thing there, and not enough appetite to try for it.

My company at the time laid off my entire division. I decided it was time, needed a job of course, and so applied for and landed a job as a "senior SWE".

This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.

This was after they encouraged a certain "cool culture" for a couple of months due to the lack of direction. It was pretty funny that I did not only get micromanaged, but was told I did the wrong thing, and then asked to do a third job that was not my responsibility.

And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev.

* the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.

Your tedious tasks are important. But some of your research/autonomous work is important as well. But both are sometimes hugely wasteful as well. I'm regularly reminded that someone more senior can ascribe "business value" to something and push that to the top of your priority list even when that thing isn't valuable.

To me, as a manager, it's worth thinking about it from the perspective of praise. People might feel better if you're reminding them that the tedious stuff IS actually important, IS actually valuable (and why), and etc. And it's important to tell folks to share their side/research efforts as well. I've neglected to share so many of these little efforts over the years, but feel that they're almost always well received.

Last part said a different way. Share something, get the response, and then do what you can to connect and make it more relevant to a real problem or issue if it's not already.

So yes, we have happy developers that have good morale. But we also have probably twice the number we need because nobody put their foot down and said "this is work, not play".

Or more specifically, explainable business impact.

But it's hard to explain how the code has become horrible and needs a refactor to makes it easier on devs, reducing stress, reducing likelihood of both bugs, and developers leaving.

It may not be a matter of "the best". I have taken a personality test that had an item on it that covered product lifecycle. If 1 is initial conception, 2 is prototype, 3 is initial release, 4 is major enhancement, and 5 is maintenance, my personality is that I prefer 2 or 3. By 4 (major enhancement) I start to get bored, and by 5 (maintenance) I'm definitely bored.

It's not that I'm one of "the best" (though I like to think that I am). I have a personality clash with the later stages of product lifecycle.

Is that the premise? Seems to be saying that constantly changing skills exhausts developers to the point that it becomes more lucrative to work in another profession.

Although, I suppose learning new things just to tread water can be boring too.

Doesn’t have to do with boredom so much as maximizing potential.

Or a reorg happens and you land a shitty manager.

To be fair, almost all my managers were amazing, people who truly cared about their staff: at professional level as well as a personal level.

I've only had one absolute psychopath as a manager ... but I should thank him because he was the last straw and gave me enough courage (and anger) to leave AWS and start my journey as a solo entrepreneur.

The thing is, executives measure themselves by how quickly they get promoted into the next role, so no one cares that good management might reduce turnover in the next 2-3 years--in fact, the executive mindset is that it could just as easily increase turnover (what if we invest in their careers, and they leave?)

Now, if I really have to spend that much time prepping to interview at your unprofitable company (that most likely will go under) don’t you think that I would try my best to work at faang instead ?

As matter of fact, I was rejected at plenty of these small insignificant companies, but end up having offers as L6 at FAANG.

Be humble and you will find plenty of good engineers out there.

I know tons of good swe that don’t want to interview/ work at mega FAANG, and if I was running a business I would definitely try to attract those talents by being different. Offering a “normal and reasonable” interview process along with better perks, flexibility and wfh.

Instead, they all want to run bizzilion of micro services in k8s

I am constantly interviewing candidates for roles at my company. It seems like CVs are a complete gamble. Either some are lies, or wildy understated, and everything in between -- at all levels of experience! "[J]ust to prove..." and yet so many can not do the 2022 version of FizzBuzz. I am stunned how many senior (well, so they say!) hands-on technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works. For get about explaining the finer points of sorting algorithms (honestly, very low value in my line of work).

There is no reasonable alternative to testing of some kind for hands-on techincal roles -- I am flexible about method: (1) white board coding (ugh in 2022), (2) IDE/text editor on shared PC / video chat (meh / eh in 2022), or (3) take home (the best in 2022, even if there are drawbacks for people with families).

Joel Spolsky said it best about hiring: The goal is to avoid bad hires. Average and above are fine.

I've been in software development for 15 years and being able to explain either of these things has never come up and I probably wouldn't be able to give a decent answer without reviewing the topics specifically.

I would expect most people I hire to be able to explain how a hash map works.

I'd care more about an applicant understanding the concept of a hash; or hashing in general. If an applicant shows that he understands that a hash is a magical and fascinating mathematical concept; and it can have uses in Information/Computers, that would be more interesting (to me) than someone who memorized a hash map definition.

He can always learn about a particular application of hashing (hash map, for example). But the latter shows aptitude and capacity to learn these later on the job.

Because a hash map is:

1) a pretty basic concept in data structures

2) Variations on hash maps are used all the time in the real world. If you use objects in javascript, dictionaries in python, or maps in C++, then you are using things that essentially implement hash maps.

Point number 1 is like if I went to an orthopedic surgeon and they couldn't tell me what the liver does. You can say "well the liver has nothing to do with my finger that got smashed in a car crash, so what do I care." Or you can say, "that seems like a red flag. Maybe I'd be safer choosing a different doctor."

* Note: I have no idea how often the liver comes up in orthopedic finger surgery and for all I know it's a lot. But I think you get the point.

Yes, you use them. You don't build them. To torture your analogy it's like asking the surgeon to explain how their bone saw works. Why should they know? All they care is that it cuts bone.

Analogies aside, hashmaps (in one implementation or another), arrays, vectors/lists, strings and arguably sets are very very common data structures in most modern languages. I don’t expect someone to be able to build a hashmap from scratch but I do expect an experienced engineer to have some basic idea of the pieces that go into building it as well as it’s properties (not necessarily ordered, O(1)ish sets/gets, collisions, etc). Knowing this kind of thing helps you understand when to use an object in JavaScript vs a map. Or how dictionaries differ between python 2 and 3. If you understand the underlying data structure, then you know what questions to ask.

* in python 2, a dictionary’s keys are not guaranteed to have consistent order. In more recent versions of python 3, they ARE guaranteed to have consistent ordering. This has ramifications for the code you write, and it’s especially confusing if you don’t understand hashmaps because 99% of the time, the order will be maintained in python 2 even though it isn’t guaranteed. But relying on things that are true most of the time is a very bad way to write production code :)

Yeah, I'd say this is all in knowing how to use a hash. How to build one would go into the underlying data structure.

Although I would probably ask them to specify the level of detail they want before trying to comply, and then not get the job because I ask a lot of unnecessary questions or something.

an in-depth definition would be that, followed by how you implement a hash map (thus if your language of choice already has a hash map, don't use that but show us how you would implement this classic data structure), how do you avoid collisions, maybe discuss some various ways that you could implement it and what the tradeoffs are. This would be you 'understand!!' what a hashmap is, like deeply. (I hope my tone makes clear I do not advocate for this)

on edit: I think it seems you might actually be advocating for this deep definition? If so, probably you are working at relatively low level?

on edit 2: for example if you were using Python you might say a hash map is a dict, and talk about how to use dict, the in-depth definition would not allow this. Which I think is what the other posters were worried about, being asked not to use your language's implementation of the concept but go lower and show you can make the whole thing.

I work as an ML engineer, so very high level.

If you ask for the in-depth understanding for positions that would never need it, it follows that you will be disadvantaging many applicants who might be great for the position and advantaging applicants who know at least one non-relevant thing.

Oh I wasn't trying to say that this knowledge was valuable or not. I was just pointing out that you seem surprised that experienced people wouldn't be able to provide a good answer to that question. And the answer is that in many jobs, its not useful knowledge.

What has burned me, however, cannot be tested adequately in an interview. Bad attitude and laziness. Anyone can behave well in interviews, so we've hired a few people who turned out to have a passive aggressive streak or condescending attitude that interferes with the rest of the team. We've also hired people who are really great developers ... when they work. But they're really lazy and getting them interested enough to do the work is the hard part.

Hiring is hard. I doubt I need to tell you that. There is a reason we gravitate towards hiring people we've worked with in the past, or come recommended by someone we trust.

If you can point me to extensive open-source experience on projects that roughly approximate professional coding, then fine, I'd be happy to walk through your code with you instead of doing an algorithmic problem. The issue is that that's a minority of developers... most people don't have the time or desire to do extensive open-source work outside of work hours and I don't blame them for it [2]! But given that resumes are unreliable, I need to test you somehow.

[1] No, I don't ever have to reverse strings at work. But I do have to write efficient code. And if you can't conceptualize how to reverse a string then you probably won't stand a chance at more difficult algorithmic issues I often come across.

[2] I don't recall who it was, but I once heard a very well-regarded chef say that he's tired after work and so he doesn't like to cook much at home. I have zero problem with a developer doing the same with coding! Go home and work on a hobby, spend time with your family, or smoke pot and watch netflix... I care about what you are capable of at work, not what you do with your free time.

In my experience people know these things, they just don't realize that what they're doing can be described generically.

An example: If you're in an iOS interview and ask the person to describe a graph, they will get very angry and complain that this is useless knowledge and they don't need it to get the job. But if you ask the same person to describe an UIView hierarchy, they often have no problem doing so. So they _know_ what a graph is, they just didn't know it had that name.

With that in mind, my tests shows that generic algorithm questions suck and questions themed around actual features of the product are the best. If you word the question in a way that feels relevant and is familiar to developers, they will be more likely to know the answer even if deep down the solution is exactly the same as the generic ones.

The backlash against leetcode is the same as backlash against other types of tests: most people are going to fail and most people don't like failing, so they blame the test.

I interview many candidates at FAANG, I can easily tell the ones that have prep by just doing leetcode and the ones that knows the shit.

I couldn't care less if you can solve all kinds of complex dynamic programming challenges.

I ask coding questions that you won't find in leetcode and requires problem solving skill and good craft.

And this is because I do like working with smart people and not with people good at memorizing patterns.

I think it is easier to know the shit to do LC interviews than somehow memorizing the question bank. I haven't seen many people succeed who were unskilled but managed to just memorize the questions.

I think LC style interview have ruined the interview process in the tech industry.

Note: I do ask candidates to code during the interview, but I ask things that are related to real problem, some of which, I had to solve in my day-to-day.

In addition, I put a lot of emphasis on how well they articulate their thought process, and the quality of their craft.

Also, I would not discount `past experience talk` that easily. Actually I use that to drill down in their resume to better understand their real contribution. More often than not, people just lie. They are very easy to spot. At that point is game over. I don't care if you nailed the coding. If you lie and oversell yourself you are done.

Another thing that I find very annoying is that very often interview are conducted by junior engineer, and they don't have imo the maturity and experience to properly assess candidate skills and potential. You either do well according to what their expected solution is, or you are out.

Interviewing is not just a binary process coding well yes/not. It is a little more involved.

I passed candidates that did not do well on coding, but I was convinced they had potential. Whereas I did not pass candidate that did very well on coding, but did not show any interest or passion at all.

You put the bar wherever you want. A company can decide to set it lower than what you would expect or like, but it could still make business sense, e.g. if 99%+ of hires still perform well with this bar and the company would like to hire faster.

This is related to:

> and barely get anything done. Plus the quality of their work (generally speaking) is very low

That's a problem of the performance review process. If everybody considers that someone is not delivering, that could be for multiple reasons, and even with a very high hiring bar that could still happen, so you can't rely solely on interviews.

If you don't have a good performance review process, you'll end up with worse hiring because you can't measure the impact of your changes.

> I passed candidates that did not do well on coding, but I was convinced they had potential. Whereas I did not pass candidate that did very well on coding, but did not show any interest or passion at all.

Can you do that objectively? It's very easy to introduce bias if you try to evaluate whether candidates show passion.

It’s good you like that I suppose, but it sounds absolutely bonkers to me.

The mold being answering questions about their supposed area of expertise.

I think people really like to claim that they are misunderstood geniuses who just don't fit the mold of being able to answer questions about the things they know. I have no doubt that such people exist, but I would not want to scrap an evaluation system simply because it doesn't catch every possible person, more important to me is keeping bad people out.

you seem very confident about that. In my experience LC/FAANG style interview don't keep bad people out.

But I have never encountered a company that doesn't have a on-the-spot technical interview (involving coding or math) that has had more success keeping bad engineers out than FAANG.

it's fascinating how these playbooks can recycle themselves in any number of scenarios. yes, conditioning on being an engineer at FAANG you are much more likely to get a better engineer, I'm not going to apologize for saying the truth.

e: not going to keep replying, I seem to recall getting in previous fruitless arguments with you when you suggested banning renting was the way out of California's housing crisis.

You're talking of gigantic tech companies that actually have a business interest in getting that right and you just assume that haven't done any studies about that. If you want to argue they're wrong, fine, but the money is against you on this, so more proof and arguments would be welcome.

I think we all agree that no interview process is perfect, but you're basically claiming that they're all equally bad.

It depends on the job. I have had interviews that broke the mold here and were panel discussions or more job-talk experience, and I found the interviews uniquely exhausting because they required their own set of skills to study for that were different from the “leet code” style. At the extreme end were the take home projects, which I simply didn’t have time to do for every company and were extremely unattractive to me for that reason. I actually find doing leetcode style interviews for me required the least amount of prep and was the most straightforward, especially when they were structured to leave me with time to ask and talk to real engineers at the company.

> Now, if I really have to spend that much time prepping to interview at your unprofitable company (that most likely will go under) don’t you think that I would try my best to work at faang instead ?

I feel the same way.

That said, my company and many others make the interview process much easier but still find it difficult to hire. I know this is a common problem, because I get bombarded with good job postings by recruiters and they are usually still there months later when I finally get around to responding.

This is not the only reason for the quick learner -> high dropout thing. By the article's definition, I'd be a "fast learner". Most of the industry expects me to come in already knowing what they want me to know, while most ways to obtain said knowledge are blocked by barriers difficult to bypass for non-corporates. Meanwhile, almost every corporate I get in expects me to do the same things for several months and gives me a few learning opportunities every year. At the same time, university primed me to absorb knowledge like a sponge and never get stuck on a single perspective, while corporates are complaining why graduates don't know Spring after graduating.

So somehow you're expecting me to stay while my knowledge deteriorates unless I keep it up in my own time, all the while giving lowball raises and not satisfying my desire for challenges. Yes, I get it, grunt work has to be done. But you really can't tell me you're in need of software developers when you actively push people to do the very thing you claim you don't want them to do.

That's not really the expectation... the expectation is that you'll be replaced by someone younger who's already learned all that.

The expectation for more senior people is that they'll go in to management or architecture.. or maybe burn out.. it doesn't really matter to most corporations, as their workers are replaceable.

And even as an engineering manager, I do not feel safe. I think only once you reach director level, you are protected from market hype and newest frameworks trends.

I was actually surprised because I heard so much about crazy new materials like carbon fibers, graphene, technologies like 3D-printing,... but apparently what makes a machine break are still the same things: mechanical stress, heat dissipation, friction,... new materials and processes might change the coefficients, but not the (mostly Newtonian) physics (my interpretation btw, not his words).

One could say the same thing about software engineering - true fundamental advances in algorithms and data structures are sufficiently rare that it wouldn't be a nuisance to keep up with them. But the %-age of how important those basics are relative to the extremely fast-changing landscape of tools and frameworks is much smaller (plus, one could argue that even the fundamentals see a lot of shifting ground in CS, with neural architectures, differentiable programming, not to mention quantum computing).

For example, SQL & Unix have been around since the 1970s.

Linux since late 1991.

Javascript: The end of 1995. NodeJS: 2009.

Sure, there's a ton of churn in the JS Ecosystem, but all it takes is a bit of wisdom, skepticism, and patience to avoid the hype-cycle.

Also, once you learn to build certain things with a programming language you learn the paradigms of the system you build.

For example-- Web Servers. Looking at ExpressJS vs Python Flask documentation, there are many analogous pieces, because they follow the same standards for protocols.

Another example-- data engineering / statistical computing: Checking out R vs Python packages, there are a lot of the same concepts, just in a slightly different format/language.

HTTP/1.0: 1996 (RFC 1945)

TCP: 1974 "In May 1974, Vint Cerf and Bob Kahn described an internetworking protocol for sharing resources using packet switching among network nodes."

"TLS is a proposed Internet Engineering Task Force (IETF) standard, first defined in 1999"

Considering all of this... I don't think most major things actually change that much. Sometimes a popular new framework takes the world by storm, but that's pretty rare compared to the output and churn of the ecosystem.

Especially if you’re a full stack eng who is constantly swimming over the entire stack and they keep pushing new DBs, new logging tools, etc.

There are commonalities but it is a lot of learning as you go. I used to know Angular pretty well but now I don’t remember it at all. I haven’t even gotten to really ramp on React as much because my company uses it in such a terrible way that it’s clearly not fit for.

After the first ten years software development becomes quite intuitive and you internalize all those best practices. You can be trusted to start a new service from an empty git repository. Later it gets incremental, there's a lot of path dependency in languages and frameworks and few things come out of the blue. Those that do are frequently intellectually stimulating to learn.

But interviews have been steadily getting strange and difficult (in a way not related to real life software development), at least in the last 10 years.

But doing the same to workers with 10 years of real world experience doesn't make nearly as much sense. Like hiring medical doctors by quizzing them on organic chemistry problems. Google and Facebook do it because they can and they don't know what else to do, but I don't understand how it became a universal practice.

I don't really see the difference between that an programming. Writing code is still a bunch of "if" statements, the same underlying data structures, same algorithms, etc. There's some new technology being added on the top akin to carbon fiber and the other things you mentioned but it's fundamentally the same.

The only attraction in software development is the relatively good pay. The job itself sucks. You'll spent your life sitting in a chair looking at a text editor, and that's the best part of your day as about 50% of it is distractions. You're quite unlikely to work on something truly creative or thrilling, so it's mostly a boring grind.

Then, as the article mentions, it turns out the grind was for nothing and the rug is pulled every few years and you have to start over again. The job is cognitively taxing so you'll turn into an absent person that lives in their heads, it drains your life energy.

If I would be young now, I'd say fuck it and go install solar panels or heat pumps. It's outside, physical but not too physical, thus healthy. You get to meet lots of people and you see the direct result of your work. There's no office politics and you're contributing to a tangible good thing for the world. Skill requirements don't change much.

You might come home somewhat physically tired (but over time it normalizes), with a clear head and not a care in the world. There's no overflow between work and personal life.

Chose wisely, young ones.

You go to different places and different people, every single day. That's 100% less repetitive compared to sitting at home or going to the office to see the same people.

As for the tasks themselves, it was merely an example, but even for this example I disagree. My brother-in-law basically does all of these things, both for private citizens and industry and comes across a wide array of different situations.

I'm not saying it's absolute perfection, no job is. But I stand by my point that it has a series of very meaningful advantages: far healthier, more social, direct impact of your work, no cognitive overload, no politics.

Amen. For me the advice I give the young—-go for a trade. HVAC (especially if you live where it’s hot) and plumbing to me are the most future and recession proof jobs there are. Literally by the time other folks are graduating with CS degrees and massive college debt, you have been making 70k a year for 3 years and are about to clip 6 figures for the rest of the time you want to work.

One day a computer will be able to write its own code (and that’s not that far off now), but no robot or computer in this world will be able to come to your house and fix a clogged toilet, or replace a blown capacitor in your heat pump and people will always be willing to pay nearly anything to get those two problems replaced.

As all the mid level white collar jobs keep getting automated away, there's going to be a glut of people in need of income who are more than capable of learning a trade if their ego can handle it.

Why is this “unfortunate”?

Also, sitting and staring at a text editor should not sound that awful for anyone who likes to create via writing code. Because that's how you do it. But that's not what you experience, obviously. It's about what goes on in your head.

I remember the feeling after taking a new job as a fresh graduate. It felt ridiculous that I know get paid for doing the thing I've wanted to do most of the time in the past ~12 years but I was told that you can't do that all day because you have duties. (Now the pay was actually pretty bad, even for local standards, as my first job was in an academic research institute.)

Which is btw one of the depressing thing for a lot of data engineers: we used to play with those cool distributed processing frameworks, and now? We are mostly writing some terraform to deploy cloud resources, most of the distributed part being handled by those cloud providers.

Sounds to me like switching one provider/tool by another - or are data engineers feeling bummed because the job has become too trivial / less fun?

In short, 5-10 years ago, writing mapreduce / spark jobs (or even debugging / optimizing hive jobs) was complex enough that it was often the job of the data engineer (and not the data analyst / scientist). And I do not only mean writing the data processing logic, but more importantly, properly configuring it so that the resource footprint was acceptable. This required a good understanding of the underlying framework, analyzing the job execution plan, tweaking the resource configuration, etc.

Now, writing distributed jobs is pretty trivial with most cloud providers, hence it is now purely done by data analysts and scientists. And the data engineers have switched to doing more of a devops kind of work, doing the plumbing between the various cloud components and the IaC required to provide those cloud resources to other data users. In short, you can be a data engineer and have absolutely no clue on how distributed systems are actually working, this will not be an issue in your daily job.