Imagine measuring a marksmen not by how accurately they hit the target with a single bullet, but instead measuring how many bullets they use, and assuming the ones that use more bullets must be better.
"Look at these so called marksmen. They don't even fire on most patrols! They average like one round! Meanwhile this guy fires off hundreds a day!" - Me, a machine gunner on the side. Cranking out tons of bespoke garbage for my not remotely software job.
This is why bad managers think this way. Bad managers are very visible because they are always fighting with their mismanagement while good managers make sure operations are smooth, so you hardly hear about them.
The thing is, there are bad managers that think like this and then there are the managers' managers that know very well that is not like this, but use it as it was just because is a good strategy for them.
I know people who generate multiple programs full of bad code for something that could have been done in 3 lines. Those constructs always fail, and then they can heroically fix it.
There was this anecdote about an electrical engineer named Charles Steinmetz who solved a problem and sent an invoice to Henry Ford for $10,000: * Making chalk mark on generator $1. * Knowing where to make mark $9,999. Most of the time you're looking for where the problem is and not actually writing any code.
3 วันที่ผ่านมา +9
unless you are a 10X programmer, then you are just writing code until the problem is no longer to be seen PS: i did not say it was fixed or solved
When you work at a software company, you don't always get to choose the project you're on, in most cases you're maintaining or adding to code that's been already written. Your job is to add features and fix bugs and every now and then you get a project that you get to create something from scratch -- but even then you're most likely borrowing from someone else's code. No one starts with a "Hello world" for anything other than basic programs. You can't be a 10x programmer (whatever that means) without knowing how things work
That report maker: "They only changed one character in the file, they didn't do anything." CrowdStrike: *Heavy sweating* (Though you could replace CrowdStrike with any conpany where some of the workers know that their codebase includes a regex.)
Regexes are amazing when you first learn about them. Then you have to maintain them or worse, someone else's regexes. From that day forward, you will probably consider if a simple string comparison is sufficient.
@@X-Bit-Gits As I'm really just learning about them formally recently, but have heard about them before, I do try and split up the components of a Regex to keep them manageable and recognizable. But the big issue with them seeming amazing is that they kind of are - in a "rm -rf /" way more than they seem at first, and then you realize they can do so much damage. Speaking of which, "rm -rf " is one of those other lines that causes heavy sweating when someone claims it doesn't do much because of a small change to the line.
@vayne7556 haha. We had a 52-line regex for validating top-level domains with country code support. As soon as I saw it, I thought: "Gee, I hope I'm not working here when that breaks / needs updating"
A few months ago I made a 1 line change to fix a several year old bug which led to a 99% decrease in redis usage, saving the company tens of thousands of dollars a year. I guess the 2 days I decided to spend investigating and diagnosing the issue because the numbers didn't make any sense was just me slacking off because the code took 30 seconds to write...
@@ildar.ishalin.chelovek 50% of the posts on tech-related videos are people parroting things they saw on those types of videos. The other 50% are the people who write "Sir" every other word.
I once spent 4 months on a bug, researching, debuging, meeting with SME and stakeholders. It also needed detailed system knowledge. In the end I changed two lines of code and it saved the company millions in less than a year and was our most beneficial software change. I'm now in management and It's my go to example whenever any one talks about lines of code as a metric, that said no-one who knows what they're talking about has every proposed that.
Personnal experience from an early job at a mobile phone manufacturer: Phones were randomly dying from corrupted file system (plus random non fatal crashes we didn’t initialy understood as connected) to the point they were considering closing the division. Our team, out of despair, put a logical analyser to the uC memory bus and coded an assembly dump decoder so that we could read the 800 pages trace of the 2s before each instrumented crash. 10 person × 2 monthes later, someone noticed the problem in the 4th dump and probably did the smallest code change that saved a thousand jobs: double the interrupt masking instruction. When we told the chip manufacturer of their product flaw, they replied they already knew it and indicated that in a footnote in the chip 2500 pages documentation.
"Sorry, random aerospace engineer. Your work contributed the least amount of weight to the new aircraft design. Clearly, you aren't working nearly as hard as Gerald over here. We're going to have to let you go."
That reminds me of a software project we had a while ago when I was a student. We were 5 people and I was definitely not the hardest working among them, but got the best grade since we used my Git to push all the code and the supervisors thought I did all the work 😂
First of all, 100% not surprised that some Stanford MBA went and wrote an "engineers are useless" charticle. Very retweetable, which is what I think unfortunately drives a lot in academia these days. I will say, I've been watching your short form stuff for a while, never seen a long form Alberta video, and I really liked it! Keep making long form content! Software engineering content that's actually relatable to software engineers!
The other way around is after all an open goal... And as this video goes on, wow. is the original source horrible "research".... The person who did it is utterly incompetent. But I guess they get measure by the number and length of papers they "produce", rather than the quality of their work.
don't confuse "business schools" with academia. Academia is about doing shit work 100 people will read not retweets. Business School is about building your profile via whatever means necessary to get a massively high paying job that doesn't need to exist in the first place.
It is possible 10% of engineers dont do any work, but it is as plausable 90% of MBA:s do no or even negative work if you would measure productivity, as in products or services your company can sell per cost of the work put in to produce that.
8:00 That last part hit close to home for me. I'm not writing a lot of new features so I don't get to show off often "hey look at this cool new thing I put together" but when there's an incident at 5am, I'm the one who gets paged.
I got much more work done in the shower thinking about the implementation details of the system I am working on than in front of the computer writing the code, I rest my case
Similar for me. Shower thoughts can be more productive than actual work hours. Sometimes the logic/solution/aha moment just happens to come during shower time. I realized this when I was in college (probably before college actually).
Omg I do that too. Whenever I have to deal with an issue I can't wrap my head around and don't even know where to start, a shower is usually the solution
"just a one line code change" yeah that was a high priority security issue we luckily got a crash report on and it took hours of problem solving and debugging to figure out why a use after free was happening. Super important fix since that was a vulnerability, but only maybe 2-3 lines of code change in the end.
Yeah MBA's like this aren't worth the cost of the paper their degree is printed on. If this was true, it would highlight how inept management is at a company.
As a software engineer, I have not written a line of code in the last four weeks, yet I have been extremely busy. HOW CAN IT BEEEE ? cough Research Trimming Planification Specification Documentation Communication cough It's almost as if the job of an engineer involved a lot of complex tasks that must be woven together to achieve great quality of production.
This is my third month at my most recent job as a ghost software engineer. They hire me because they are "negotiating a lot of projects" but again it is almost three months and nothing. It's not my fault and I actually prefer to have at least a goal, a task or something. No meetings, no code reviews, no deadlines, no PM, no check-in or checkout, just a call once a week from my boss telling me that they are sorry for putting me in stand by, that they have a lot of work with other projects and that maybe next week projects will start to take off (this happen every week since I started). It's kinda the opposite of being laid off for doing nothing; they hired me to do nothing. It feels like "big head" from the SV series hired by Hooli. Anyway, they pay me, they know it and they are ok with that, so everyone is happy. Btw if someone needs a ghost software engineer (or an actual real software engineer) I have a lot of time available.
Day in the life of a real software engineer: No free breakfast, had to take kids to school, just about get into work in time to pretend to listen to what anyone else says during stand up while I wait for my turn to speak, back to back meetings, try to get some actual code written over lunch, some more meetings, pick up kids from school, try to get some code done in the evening, go to bed exhausted
My day: Bike 30 minutes to work, eat free breakfast, go to some meetings, hit the free gym during lunch, unless it's Friday cause we get free lunch on Fridays, Tuesdays we have a personal trainer, Have another useless meeting, Maybe get some code in before leaving. Some days I wonder why they hire us to begin with. They can't possibly make money
@@timonix2 All the work is done by a single autistic guy, who has been programming since the 80ies. You guys and the workplace just exist to enrich his environment.
@@timonix2 "Quarterly objectives were significantly exceeded. Our Human Resources grew by 30% year-to-date and is indicative of a positive outlook for the subsequent quarters."
Thank you for saying that, out loud, for the world to hear. Engineers build stuff, and make it work. That's what they do, no matter how obscured that goal may be. Everybody else, it seems, "makes plans" (and meetings about plans, and plans for plans (seriously)). "Making plans" is definitely "work". But are they useful? In my experience, "plans" (including design, architecture, and especially 'schedules') are almost always made by non-technical folks, and certainly without communicating with the technical folks in any way. So they're wrong, usually hilariously wrong. I've noticed that such folks are all about making and remaking plans - but are absolutely resistant to using any past experience in creating these plans. They'll make a whole new plan in a heartbeat, but will never consider looking back at previouus plans, to try to learn something. It just isn't done. Hence same mistakes, over and over and over. Engineers sigh, look at the new plan to see if it affects them, or the existing work, or the project in any way. Usually they don't. If they don't, the engineers ignore the plan and keep doing what they're doing.
The MBA is the natural enemy of all engineers. I am a field service engineer for semiconductor fab equipment. I have worked places where idiot MBAs had metrics to measure our productivity based on how much of our time was utilized. Look, if I was the best field service engineer in the world, I'd spend most of my time drinking coffee, because I would prevent problems in 10 minutes instead of fixing them for an hour, before the tools went down unexpectedly. You DON'T WANT FIELD SERVICE ENGINEERS TO LOOK BUSY. That means your equipment ISN'T WORKING.
an MBA grad is the natural enemy of shit getting done since all they wanna do all day is talk about spoons and tshirts and some weird points while sitting in a standup meeting
English is not my first language. What is MBA? Master of Business Administration? Management Business Administration? From the context of the video it sounds like Alberta was talking about a economy/business related "study".
It's the quantitative fallacy. People mistakenly believe that what matters can be measured and what can't be measured doesn't matter. There's also its close cousin, scientific management, which persists despite being thoroughly debunked.
I really liked hearing what you had to say. I’m an Electrical Engineer who also writes some code. They really shouldn’t look at non-software engineer code quality or we would all be gone!
I love that reminds me of my father who was senior editor for a major newspaper, who got one day a call from his boss that he does too much journalism, and he shouldn't do that because they don't pay him for that. They rather have him do nothing than work as a simple journalist, instead he done his doctorate on mostly company time. It makes sense because as senior members for example are responsible for taking up the slack when disruption happens. If everyone works at 100% capacity then the organization has zero resiliency.
The one line changes are usually the crazy hard to find bugs that take days of debugging to hunt down, these people are delusional if they think code quantity == better
The crazies "one line code change" I made came about after a freaking week of debugging. It wasn¨t a true one line code change though, since in the process of debugging I had also added a bunch of comments, all to help with the analysis needed to do the debugging. What was the change? Just a simple off by one error. What made it hard was that it was happening in the middle of complicated custom multi-stage recursive algorithm that was hyper optimized. We had to draw a ton of diagrams out for what was to be expected for each freaking stage of the algorithm and go through and try and figure out when something was not right, and making sure that our assumptions on what it should actually look like at each of those stages. I had multi-hour meetings where we just was pouring over the diagrams on a blackboard and trying to poke holes in our possible assumptions on what each stage would like like and whether we should split it up differently. On the bright side, after that hellish debugging, any bug that takes less than a day to solve feels reasonably quick.
Yeah like these people don't realize that actually the less you write the better, imagine the amount of tech debt you can acquire by writing redundant, unoptimised code. If I want many lines of code I could just copy paste the same function and rewrite some minor things inside 100 times instead of making it a generic function that can be applied to many use cases
"ghost managers" is definitely the phrase that hammered home to me that point here is to deny the personhood of the people who actually do the work alltogether
"An MBA grad is the natural enemy of the software engineer" This has big "Have everyone print out all their git commits so we can get rid of the least productive programmers" energy
Normally, showing your code online would be a pretty good way to lose your job. If anyone ever saw it. But like you said, it wouldn't go viral, no one would see it.
EXACTLY! I've seen people get fired for posting snippets of proprietary code on Stack Overflow. Most organizations are pretty clear about "do not film little videos here and do not talk about your work on social media."
While(water.sparklyness < config.sparkeltarget && container.pressure < config.thatsdangerous){sparklegenerator.process(water);} Noooooooo! You leaked out company secrets! 😭
"9.5% of engineers dont work" - a guy who seemingly has no idea wtf engineers actually do. We dont whip up a completely new piece of software every day. You know what, yes, lets measure productiveness by quantity of code, then we will all just add comments and you will wonder why nothing ever changes about the apps you rely on.
It cost $1 for me to make that 1 line change, the rest of my salary is from the 15 years of experience it took to know which line to change and to be the kind of person you can trust to change it. (paraphrased from an old story)
When the internet IS a series of pipes, it seems pretty apt to apt a joke about a plumber (at least the original version of this joke I heard was about a plumber)
Anyone who's ever dealt with a 'mature' build pipeline knows what those are: I can't build/release from my machine so i have to commit every step in a larger change, or "oh the person who originally wrote this can't spell/doesn't follow the convention"
2:26 Guys she's just jealous she doesn't want to admit that her sparkling water company doesn't have the same perks as the other sparkling water companies.
As a tech lead; yes all of this. For very large parts of my career I've primarily written code to provide examples to juniors to unblock them, and commit very little myself. I'm paid to figure out what needs changing, how to do it safely, etc. not to make the changes myself. The main complaint I hear from senior engineers and above is they don't get to write code any more because other things need their time, this guy has just rediscovered things we've all been saying and drawn a terrible conclusion.
“I take the specs from the customers and give them to the engineers…” “You physically take the specs from the customers?” “Well…no… my secretary does that….”
2:20 Also, I don't need to be a software engineer to know that livestreaming their actual work would probably get most corporate devs fired. There's a lot of closed-source code out there.
Would be a shame if the entire SRE / Ops department got laid off. Oh...what is that ? An outage ? A security update ? AWS updated their service and broke the website ? Good luck solving that.
If someone asked me if my primary job was writing code, they would be met with the most pained laugh they've ever heard. My *job description* is writing code. My primary jobs include: researching existing code meeting with stakeholders about what they want meeting with stakeholders about what other stakeholders want meeting with stakeholders about what they ACTUALLY want because they don't want what they said they wanted teaching juniors how to work with the codebase teaching managers our jobs are
That is so true! Coding is not that hard, about 80% of the people out there would be able to code. The hard part about the job is understanding the needs of the customer. There are so many memes about this topic!
MBAs have been trying to get rid of costly software engineers since at least the 80s, but no low-code, no-code, or LLM based solution will ever replace us for exactly the reasons you outline. Software engineers have to navigate both human _and_ technical challenges, and addressing both together is the real value that we bring
NASA writes some of the best code on the planet BECAUSE they spend two years talking about and writing up documents on what they're going to code before coding it. Because when your computer is orbiting Saturn there's no on-site service.
@dtw8446 Most software engineering shops aren’t making aerospace-grade software, and those meetings (actual planning meetings) aren’t the ones that the comment you’re replying to is talking about (daily standups and other “status update” meetings)
@@dtw8446 We ain't writing code for space ships but even if we were the meetings I'm talking about wouldn't keep anything space worthy. It's literally opening tickets to cover multiple discoveries for 10 minute tasks. Then a 5 meetings about that 10 minute task where the same questions are answered over and over again. It's endless bureaucracy for the sake of bureaucracy.
8:42 And yet, with post-COVID work from home + GPT-4 level LLMs coming out to accelerate writing, documentation and communication tasks, I can certify there's a lot of "ghost" managers now too. Should they be laid off? Absolutely not! If any worker, top to bottom, figured out how to axe 80% of their workload through WFH convenience and AI, we should consider that a step towards post-scarcity personal empowerment, not an occasion to put back money in shareholder pockets!
Criticisms of capitalism aside, I'd like to see these managers become contributing members of society rather than having decision making authority to rain down misery on the lives of innocent people.
Dear Alberta, Thanks so so much for bringing attention to people's livelihood, legal status, etc. that that individual simply did not care. The greed that is companies and managers are never the problem as long as I benefit from them and it is all the hard workers that are the problem is very upsetting.
I searched him and he himself is an immigrant came based on a student visa. Just why? Clearly he knows what is at stake. Given the political climate. As you said, Alberta, the terms he used ("ghost" etc.) is for attention. Also, as you said there seems no other paper. It seems he just started to publish.
This is why it's so important to distinguish between "coding" and "programming". The great majority of the work of a SW developer is in _solving the problem_ , i.e. figuring out *how* to do it---deriving an algorithmic solution---and designing it. Coding it is the last and least important part of the work. That's why measuring productivity of a programmer by quantities like lines of code or time spent behind the keyboard is extremely stupid. I do not put my ideas about the problem in a drawer when I "leave the office"... And you still meet a lot of managers, even people who supposedly should understand SW development (like "agile coaches") who suggest and promote exactly that. Guess who isn't their employee any more... ;-)
Once I chased a memory leak for 3 weeks only to commit ONE change on a boolean value in a DBus call (the sent message was never freed, useful when you malloc it by hand or even allocated statically). Not to mention the time spent to find a reliable tool, given valgrind would not have compiled on the SH4 based board I was working on.
Yep. I implemented 90% of my system using event sourcing to avoid race conditions. Naturally I spent 90% of my time hunting down race conditions in the other 10%.
Even if valgrind compiled and ran, it would most likely emulate an x86 machine, so it wouldn’t be useful. In my case it was armv4 before valgrind gained proper support for that. I was very impressed with myself for getting it to build and run, the people in my team that had requested valgrind weren’t :)
@@KoenKooi haha maybe, I didn't reach that point anyways. I ended up by hooking all calls to malloc/free & new/delete (not my code, but from a genius that happened to be a colleague of mine). Unsure if instrumented processes where LD_PRELOADed ou recompiled, but the output was a PITA even with python script to preprocess it :(
I’ve worked with 0.1x developers, and I’ve seen devs getting axed in mass layoffs (and I’m one of them). In my experience these two groups have no correlation. In my experience, mass layoffs fire less necessary or less profitable groups of devs, but that not always has to do with devs individual performance, it often has to do with what useless project idea managers decided to put those devs (0.1x or 10x) on. When I got laid off as an example, company fired all full stack web devs because they couldn’t get enough client projects that needed our services, but they kept all rust crypto developers because they had one big client that needed them. A few months later this one client closed their contract, and now those devs were laid off too. It had nothing to do with individual performance
So true and that’s one of the bad things of software engineering. You can for sure be blamed if something breaks but on the other end, it’s usually the product people who get the praise if a feature performs really well. And no matter how great you are at your job, if you have to build something that users won’t like, that won’t look great on you.
The MBA is the preferred degree for glue-eaters with familial wealth. As a general rule, I really don't trust anything an MBA has to say unless they can demonstrate basic competence in whatever they're talking about. This generally does not happen.
when a MBA hears that the dev team is developing something they isntantly feel like they need to be doing something at all times or they aren't working and thus they proceed to fuck with every single detail available to them and in the process slow everything down and fuck up the product so it's delivered wrong and late
As someone who works in big tech this is 100% true for people who I work with directly. There are people who work too much and people who don’t work at all. I’ve been both. You’re giving the benefit of the doubt to these “day in the life” influencers who show off doing nothing.
I was once flown to Europe last minute to identify and fix a software bug, the fix boiled down to multiplying one thing by -1. Customer was happy bug was fixed and ok with what it cost.
Multiplying one number by -1: $1 The expertise to know where and how to make that change, and test that it is correct: $10k Having managers that understand that math: Priceless.
On the behest of a large management consultant company mine implemented an engineer performance monitoring tool based on lines of code checked in. I noticed many engineers hard-coding items that should of been config tables as it resulted in lots of needless lines of code (among other far worse practices), great for their 'performance kpi'. Performance line went up......then again so did all the defects as our codebase became a nightmare.....It now takes 5 times longer to deliver features. So we have hired another consultancy firm to transform our ways of working and get things back on track. I am sure this time it will be different.... These MBA's / Consultants are the enemy of productivity, not it's savior.....
I was watching some videos on a similar topic earlier today, a video of a girl showing a day in the work of working at Google. And they showed all those perks and fancy stuff as well as meeting time and coding time. The amount of people who said things along the lines of "meetings don't count as real work, she wrote like one line and worked for 5 minutes they should fire her" was disturbing.
I wonder how much if any of this is also inspired by younger startup minded people who are used to move fast and break things environments where they are trying to build there hackathon app and publish it as fast as possible, working on small code bases on small teams. I feel like as codebases get larger and responsibilities get more real meetings become more of a thing.
@@SimplyWondering I spent a year isolating out a crash that only affected clients using high-definition monitors and another year to get the changes implemented. The novel of JIRAs and the legion of meetings were a thing.
@@albertatechOf course she is bad at C++. Everyone is bad at C++, especially people who think they are good at it. She is probably good at her job though.
This is the reason I hate the "lines of code" metric. We used to have a "gamification page" where everyone's commit frequency (along with lines changed) was put on display for everyone. Of course this led to people getting "you're underperforming" talks. It wasn't until the most senior devs (who obviously have less code changes than your average intern) complained that the page was discontinued.
Performance is a team dynamic. I have on days and I have off days. Sometimes I kick off after six hours, sometimes I'm here for 12. As long as my team is meeting our deadlines you shouldn't be concerned with how much code, how many commits, how many PRs we're reviewing. The other engineers will absolutely tell you if someone is under-performing on the team (and it'll still take management 10 months to get rid of them ).
I've become a bit of a specialist in one-line fixes for bugs that take days or weeks to track down. The old joke about "turning a screw: $1, knowing which screw to turn: $9,999" is so accurate. It's incredibly satisfying to finally figure it out and get to be the hero by writing a single-line diff. On rare occasions it's even a single-character fix.
This, that thing about the single character change was so revealing that this person had no coding experience. There have been so many bug fixes that are changing < to
A one line code change often suffices to get a program from failing under specific circumstances to always working. Make sure certain variables aren't already set, deactivate active environments, don't rely on Linux or Windows folder structure, make intermediate directories, ... All can cost programmers days to figure out where the issue is. So those one line fixes may save many people many days of work.
I've been a developer for decades. I've dealt with a LOT more managers, business analysts, and marketers who productively are "ghosts" than I have ghost engineers.
Gee, it's too bad companies don't do twice annual performance reviews that incorporate coworker, manager and customer feedback. And it's *really* too bad that there are no systems out there for engineers to track their work and measure their impact on customer deliverables...
In my experience, 10% sounds awfully low. There's a lot of engineers that just aren't good. I've worked with some brilliant people and I've worked with some useless people. As someone who sometimes hires engineers, more than half of applicants can't write a CS 101 program. I don't even conduct interviews anymore. I just ask applicants to write a very simple program. It's not just engineers, to suggest that 10% of any occupation is composed of useless workers is exceedingly plausible.
Right? Like the defensiveness here is kinda baffling.. Only 10%!!? would have been my spin on it. Maybe you can't cause you don't have the data for other jobs?
Hey! Found your videos a month or two ago and my only complaint is i wish there was more long form content ! Its so refreshing to see some developer opinions that are based a bit more in reality and lived experience then what you normally find here on youtube/social media. Keep up the awesome work!
also this spoke to my soul because i just recently had a random story dropped on me and was told it was a top priority from management that couldn't wait until the following week.... took me like two hours to write and test... took six days for pr to get approved and management to hit the button to approve the change SMH
Should also be pointed out that moving 1000 lines of code to a different part of the repo still counts as "writing" 1K lines according to most change trackers. A few months ago I had a project manager call me in a panic demanding to know why I had pushed 5,000 lines of code to main without any testing, and it took twenty minutes to convince him that it was just me moving his fully tested function to the file that actually uses it to prevent import shenanigans.
Yeah, code checkins, reviews, issue activity won't show who is doing what, at all. Somehow team members don't know who is "doing nothing". Somehow managers don't know who is not working. Naturally a random journalist knows what's actually happening better than the folks actually working. Nice coverage on a lame, ludicrous "study". Thanks for your time on this.
People think programming is changing oil in a car... but it's more like trying to change the oil while the car is speeding down the highway, the manual is written in kanji, and every five minutes someone replaces the car with a spaceship.
It’s more like “engine is running slow, don’t know why” and thirty minutes later you find out a little gunk is on the throttle body and impeding air flow by 3%
I predict you won’t need to make a tearful apology video. Your take is 100% spot on. I think another reason software engineers get picked on is that nobody else really understands how complex software development is and what’s involved.
it's not just about software development, most people don't understand how complex the other fields are apart from physically demanding workers like janitors, waiters and other service people it's hard to see where "we need to replace $10 gasket, it's gonna be $510" comes from and even with waiters the part you see is "they bring me food" the part you don't see is "staying late to clean shit and close the register" and much more things i don't know about
One of the main reasons I left big tech to join a smaller, 100-person company was the disconnect between management and the actual contributors. In larger organizations, non-technical managers often struggle to identify who’s truly doing the work. The so-called “0.1x engineers” always seem to dominate discussions with endless proposals and ideas, but it’s someone else who has to implement them. Ironically, managers often perceive this as being proactive.
"One line changes can often be the most important changes." Like that one line fix that was the result of a two-week debug effort chasing down an intermittent failure? Yup, been there.
Loved this longer video. If we are going to be measured by lines of code written, I might as well forget the DRY principle and everything I learned in Clean Code.
I’ve been on TH-cam for so long but honestly, you’ve become my favorite content creator on this platform. You deserve way more subscribers. Your content not only educates me on the world of software engineering but also makes me feel better when I’m having a rough day with your comedy. You’ve honestly inspired me to research more about software engineering in-general, and you’ve definitely changed my life for the better.
I flip flop between 10x engineer and 0.1x engineer. Basically I procrastinate the actual coding while thinking about the implementation options over several days of keeping up appearances. Then when crunch time hits I knock it out in speed mode because all the complex issues are already solved before I started.
i think thats a lot of us tbh, my whole team is like this, we go in spurts of doing a months worth of work in a week and then being burned out. as long shit gets done by deadline, everything's good
@@_stix If you or your team weren't involved in negotiating the deadline, or the details of the change weren't known at that time, that point in time isn't a deadline. If anything, the seniority of the person who chose the target date is *inversely* proportional to how much ass-busting you should do to hit it, because they don't understand the detail of your work and they won't notice or care about your extra effort. "When will you be releasing this change into production?" "When it's ready." The only exceptions should be regulatory, legal, or contractual, or if you're not at risk of burnout, self-imposed (or agreed with collaborators) to finish something you personally care about before you (or your collaborators) take a holiday, move roles or leave the company.
As an SWE with 10 years in the same workplace, I have to say I partially disagree. To be clear, most of what you said is correct - What I'm getting at is, IMO there are employees who consistently bring MUCH less value to the workplace, just like there are those who consistently bring more value. Sure, there are built-in processes to identify and remove low performers (e.g. yearly performance reviews). But those processes are not perfect, and there are employees who definitely "slip between the cracks" and continue to do jack shit for most of the day. I work in a big corporate, and due to management oversight it can be ridiculously easy to get away with doing the very bare minimum and sort of "padding your work" to make it look like reasonable output per-day when in reality you spent 7 hours on social media and 1 hour coding. I used to do that myself, for weeks at a time - especially when I didn't have clear deadlines for anything. I suspect that in "leaner" companies this would be much harder. Is it 10% of devs? IDK. A less sensationalist headline that is closer to reality would be "small % of devs get by with doing basically nothing and are a waste of company resources." But I feel like that is kinda obvious anyway.
I learned the hard way. I bashed out a mockup of a feature I wanted to implemented and gave it a frontend in a framework I'm comfortable with over a weekend. Tough trying to explain just how long it's going to take to implement it in our actual codebase
I'm just so thankful that you took the time to make this video. It's so overwhelming to try and combat this type of bullshit to people who don't know what software engineers do
I spent hours this week in meetings for a "1-line change". Sure the change enables a feature that cannot leak before the official announcement, and needs multiple teams to be ready, but those are irrelevant details.
One of the problems is calling hs "programmers". We are software engineers. Software engineers research, plan, and then implement. Saying we're "programmers" makes it seem like all we are supposed to do is implement, when a lot of it is the research and planning. But I wouldn't expect an MBa to know -anything- that
Um. I'm going to take exception to that. Sorry. I'm a computer programmer. I have yet to hear a definition of software engineer that I can make sense of. Maybe I'm just not smart enough to understand, but I've known and worked for engineers most of my life and it's not clear to me that software development is, or ever can be an engineering discipline.
@@quintrankid8045 So you are stamping punchcards for the computer then (not acutally figure out where the holes go, just usinging the stamping machine)? Engineering is excatly what it sais, design of software to work as good as possible, just like a aironautic engineer optimises the workings of a plain for a problem.
@@ameier5570 That's not the definition of engineer I was taught when I was a young 'un. But I suppose nowadays we can make words mean whatever we want. Optimizes is an interesting word. When you write software what do you optimize for?
@@quintrankid8045 Engineer = "a person who designs, builds, or maintains engines, machines, or structures". at least that is what google sais and yes technically it doesent involfe software in that definition. And for what you optimise depends on the case, sometimes speed is more importand then maintainability sometimes you have to optimise for low latency sometimes you have to structure it a sertain way, the list goes on. The answer is as almoste everywhere in IT: "It depends". But i asume you are a expierenced IT person so i have to assume you know that already, so why do you try to test people?
@@ameier5570 From my view that definition doesn't include the mechanical engineers who do fluids or chemical engineers either. I'm not testing, I like to know how people think about things.
Shorts are like snacks. They're cool and all, but you can reach the point of having consumed too much, and yet still need the satisfaction of a proper meal I have pretty bad ADHD but I love watching multi-hour YT videos from channels like: - Well There's Your Problem (a podcast about engineering disasters, with slides) - Drachinifel (a naval history channel by a qualified engineer, his Dry Dock Q&A videos run long, especially the monthly Patreon-questions-only episodes. Record is over 5h iirc) - Perun (an Australian who studied historical war economics at university, now works as an analyst in the military industrial complex down under hence the pseudonym, pivoted from a gaming channel to weekly PowerPoint presentations about war, logistics, supply chains... Very funny, and he's interviewed and been cited by known experts, and generals retired David Patreus and Ben Hodges) - C&Rsenal (the history of firearms, one gun or family of guns at a time. Covers the designer's background, how the design built on prior art, its testing, adoption, service history, a practical demonstration and a review of its performance and ergonomics)
I once spent 4 months on a fault, researching, debuging, meeting with SMEs and stakeholders. It also needed detailed system knowledge. In the end I changed two lines of code and it saved the company millions in less than a year. It was our most beneficial software change ever to date.
Omg, like managers are the worst investment ever, they produce zero lines of code, and are always giving their work to everyone else. What even do they do? How is telling Bob the engineer to work on a feature worth their salary? Anybody could tell Bob the engineer to work on that feature... /s
I work in big tech. There are lots of engineers who don't write a lot of code. We even have silly names for them. I think we call them "managers" and "tech leads".
For me, it's fine if the manager or tech lead for the engineering team doesn't write a lot of code, but if they don't know how to code, it's a real problem imho. And believe me, I've already seen some of these cases. 🥲
Wow. It's quite a stretch to imagine that if someone doesn't show EVERY part of their job, then they must not do those parts they don't show. Thank you for properly explaining that someone who finds and fixes a tiny thing might be as or more productive than people who do tons of lines of code. It reminds me of this quote from fortune(6): A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing spoke sternly: "You can not fix a machine by just power-cycling it with no understanding of what is going wrong." Knight turned the machine off and on. The machine worked. The novice is the person with the MBA pretending to understand programming.
I'd probably get counted in that category. A commit of mine gets merged once every ~6 months. However, each of those commits usually represent months of prototyping, experimentation, and other R&D type stuff. Different types of work require people to work at different paces
Alberta, I've come across your content recently through shorts and it's quite nice. This is the first longer video of yours that I've seen and I'm glad i have. As an engineer, I've come across some ridiculous takes after this article got traction and it's not only refreshing but absolutely necessary to have people like yourself questioning the focus of this article. Workers are not the problem, much to the contrary. This whole thing seems like yet another attack on this rare section of the working class that have achieved a reasonable level of compensation. Anw, great content. Cheers
Regarding sloc counting... I am "senior" engineer, and quite often one younger padawan is asking me for help. And most of the time, after review, line count is getting much lower, with resulting code being much more readable and doing exactly the same as initially intended. More code != better code. We don't have such metrics in our company, but looking over commits - I have "windows" without commits, but not because I didn't work, it is just that reading requirements, doing research - doesn't go into commits. And even if I code something - it might be that the changes I made are not yet ready to be committed, as I prefer to smoke test before that. For some reason I even feel uncomfortable to change the code I recently committed, as someone would think that I couldn't get it right from the first try. But still, I am happy that our company doesn't analyze quantity of code, top priority - to implement features before ETA, and to have less bugs.
3:55 i think there was a lot of cuts here and it made it a bit difficult to keep pace with you speaking, still really good video!!! love the longer ones
Sometimes, I wish devs would do nothing. This giant machine doesn't lack speed, it lacks manoeveravility. Btw, I can just second the notion that developing is mostly NOT about coding. Writing it down is mostly trivial. Understanding and deciding the right thing is the hard part.
Imagine measuring a marksmen not by how accurately they hit the target with a single bullet, but instead measuring how many bullets they use, and assuming the ones that use more bullets must be better.
"Look at these so called marksmen. They don't even fire on most patrols! They average like one round! Meanwhile this guy fires off hundreds a day!" - Me, a machine gunner on the side. Cranking out tons of bespoke garbage for my not remotely software job.
This is why bad managers think this way. Bad managers are very visible because they are always fighting with their mismanagement while good managers make sure operations are smooth, so you hardly hear about them.
Reminds me of an old joke that went "The repairman charged me $1000. $10 for the part he replaced and $990 for figuring out which part to replace."
The thing is, there are bad managers that think like this and then there are the managers' managers that know very well that is not like this, but use it as it was just because is a good strategy for them.
I know people who generate multiple programs full of bad code for something that could have been done in 3 lines.
Those constructs always fail, and then they can heroically fix it.
There was this anecdote about an electrical engineer named Charles Steinmetz who solved a problem and sent an invoice to Henry Ford for $10,000:
* Making chalk mark on generator $1.
* Knowing where to make mark $9,999.
Most of the time you're looking for where the problem is and not actually writing any code.
unless you are a 10X programmer, then you are just writing code until the problem is no longer to be seen
PS: i did not say it was fixed or solved
When you work at a software company, you don't always get to choose the project you're on, in most cases you're maintaining or adding to code that's been already written. Your job is to add features and fix bugs and every now and then you get a project that you get to create something from scratch -- but even then you're most likely borrowing from someone else's code. No one starts with a "Hello world" for anything other than basic programs. You can't be a 10x programmer (whatever that means) without knowing how things work
What is a 10X programmer?
@@YDV669Exactly.
Imagine if some engineers are testing the products instead of writing code. Terrible. Everyone knows to leave the testing to the customer.
Testing the products we build is obviously beneath us 🙄
Works on my machine, good enough for prod.
@@albertatech as someone who has MS Teams forced upon me I can tell you're a real engineer. ;-)
All tests pass 🤗 :lgtm:
Testing? You sound like one of those people who compile and link after making code changes.
That report maker: "They only changed one character in the file, they didn't do anything."
CrowdStrike: *Heavy sweating*
(Though you could replace CrowdStrike with any conpany where some of the workers know that their codebase includes a regex.)
Regexes are amazing when you first learn about them. Then you have to maintain them or worse, someone else's regexes. From that day forward, you will probably consider if a simple string comparison is sufficient.
@@X-Bit-Gits Wdym? Don't you love debugging regexes?!
@@X-Bit-Gits As I'm really just learning about them formally recently, but have heard about them before, I do try and split up the components of a Regex to keep them manageable and recognizable.
But the big issue with them seeming amazing is that they kind of are - in a "rm -rf /" way more than they seem at first, and then you realize they can do so much damage.
Speaking of which, "rm -rf " is one of those other lines that causes heavy sweating when someone claims it doesn't do much because of a small change to the line.
@vayne7556 haha. We had a 52-line regex for validating top-level domains with country code support. As soon as I saw it, I thought: "Gee, I hope I'm not working here when that breaks / needs updating"
@@X-Bit-Gits *That* sounds like a nightmare.
But out of curiousity: was this 52-line Regex 80 characters across for each line?
A few months ago I made a 1 line change to fix a several year old bug which led to a 99% decrease in redis usage, saving the company tens of thousands of dollars a year. I guess the 2 days I decided to spend investigating and diagnosing the issue because the numbers didn't make any sense was just me slacking off because the code took 30 seconds to write...
Looks like a Primeagen react article, lol
@@ildar.ishalin.chelovek 50% of the posts on tech-related videos are people parroting things they saw on those types of videos. The other 50% are the people who write "Sir" every other word.
should have just known where to write the code change on the top of your head lol
I once spent 4 months on a bug, researching, debuging, meeting with SME and stakeholders. It also needed detailed system knowledge.
In the end I changed two lines of code and it saved the company millions in less than a year and was our most beneficial software change.
I'm now in management and It's my go to example whenever any one talks about lines of code as a metric, that said no-one who knows what they're talking about has every proposed that.
Next time you need to write at least 10 extra lines of code to justify making any change at all.
Personnal experience from an early job at a mobile phone manufacturer:
Phones were randomly dying from corrupted file system (plus random non fatal crashes we didn’t initialy understood as connected) to the point they were considering closing the division.
Our team, out of despair, put a logical analyser to the uC memory bus and coded an assembly dump decoder so that we could read the 800 pages trace of the 2s before each instrumented crash.
10 person × 2 monthes later, someone noticed the problem in the 4th dump and probably did the smallest code change that saved a thousand jobs: double the interrupt masking instruction.
When we told the chip manufacturer of their product flaw, they replied they already knew it and indicated that in a footnote in the chip 2500 pages documentation.
Just completely normal two months in the live of a developer. 🙈😅
"Sorry, random aerospace engineer. Your work contributed the least amount of weight to the new aircraft design. Clearly, you aren't working nearly as hard as Gerald over here. We're going to have to let you go."
oh thats a good one 🤣
That sounds like Boeing 😂
That reminds me of a software project we had a while ago when I was a student. We were 5 people and I was definitely not the hardest working among them, but got the best grade since we used my Git to push all the code and the supervisors thought I did all the work 😂
😂 this IS how “management” measure things in software, often.
,,But wait, my job is weight reduction!”
Code is not a resource, but a liability.
Good engineers figure out how to do a lot with very little.
Mediocre engineers just vomit a lot of code
My favorite commits are all code subtraction.
First of all, 100% not surprised that some Stanford MBA went and wrote an "engineers are useless" charticle. Very retweetable, which is what I think unfortunately drives a lot in academia these days.
I will say, I've been watching your short form stuff for a while, never seen a long form Alberta video, and I really liked it! Keep making long form content! Software engineering content that's actually relatable to software engineers!
Very retweetable indeed 🙃 and thank you for the encouragement :)
What Bradley said gets a +1 on every individual count from me.
The other way around is after all an open goal...
And as this video goes on, wow. is the original source horrible "research"....
The person who did it is utterly incompetent. But I guess they get measure by the number and length of papers they "produce", rather than the quality of their work.
Perhaps if they'd gone to Harvard instead ... oh wait, never mind.
don't confuse "business schools" with academia. Academia is about doing shit work 100 people will read not retweets. Business School is about building your profile via whatever means necessary to get a massively high paying job that doesn't need to exist in the first place.
It is possible 10% of engineers dont do any work, but it is as plausable 90% of MBA:s do no or even negative work if you would measure productivity, as in products or services your company can sell per cost of the work put in to produce that.
"Just because it's easier to measure that, doesn't mean that's what we should be measuring" is just..perfect. Thank you
Academia is the same. Impact factors, number of publications, funding money brought in, it's all easy to measure. But doesn't show quality of work
(see Goodhart's Law)
It's the drunkard dropping his keys on one side of the street, but looking for them on the other side, because that's where the streetlight is.
8:00 That last part hit close to home for me. I'm not writing a lot of new features so I don't get to show off often "hey look at this cool new thing I put together" but when there's an incident at 5am, I'm the one who gets paged.
I got much more work done in the shower thinking about the implementation details of the system I am working on than in front of the computer writing the code, I rest my case
Similar for me. Shower thoughts can be more productive than actual work hours. Sometimes the logic/solution/aha moment just happens to come during shower time.
I realized this when I was in college (probably before college actually).
Or that 15 min nap when you’re stuck for hours on a problem and you wake up with the solution
I take a shower every time I feel stuck. It could be multiple times a day. Hot shower is a god send technique to free up a congested nose or brain.
Omg I do that too. Whenever I have to deal with an issue I can't wrap my head around and don't even know where to start, a shower is usually the solution
For real. My daily 3-5 mile walk is where I actually figure stuff out.
"just a one line code change" yeah that was a high priority security issue we luckily got a crash report on and it took hours of problem solving and debugging to figure out why a use after free was happening. Super important fix since that was a vulnerability, but only maybe 2-3 lines of code change in the end.
Once you said MBA, I knew everything I needed to know
The irony of these people talking about engineers who "do no work"
For real
Yeah MBA's like this aren't worth the cost of the paper their degree is printed on. If this was true, it would highlight how inept management is at a company.
Every experience I've ever had with a business student or business grad has been them being actively delusional. -_-
MBA - the 0.1x workers.
As a software engineer, I have not written a line of code in the last four weeks, yet I have been extremely busy. HOW CAN IT BEEEE ?
cough
Research
Trimming
Planification
Specification
Documentation
Communication
cough
It's almost as if the job of an engineer involved a lot of complex tasks that must be woven together to achieve great quality of production.
This is my third month at my most recent job as a ghost software engineer. They hire me because they are "negotiating a lot of projects" but again it is almost three months and nothing. It's not my fault and I actually prefer to have at least a goal, a task or something. No meetings, no code reviews, no deadlines, no PM, no check-in or checkout, just a call once a week from my boss telling me that they are sorry for putting me in stand by, that they have a lot of work with other projects and that maybe next week projects will start to take off (this happen every week since I started). It's kinda the opposite of being laid off for doing nothing; they hired me to do nothing. It feels like "big head" from the SV series hired by Hooli. Anyway, they pay me, they know it and they are ok with that, so everyone is happy. Btw if someone needs a ghost software engineer (or an actual real software engineer) I have a lot of time available.
nah bro, stop looking for excuses, start working already
Why does she call herself an engineer but doesn't even drive a locomotive or wear one of those funny hats. Curious.
I've never even heard her pull a rope that makes a CHOO CHOO
busted
No evidence of coal dust, anywhere. Tsk tsk.
Engineers don't drive trains train drivers do 😂
@@damiendye6623 Here in 'merica, they do.
Day in the life of a real software engineer:
No free breakfast, had to take kids to school, just about get into work in time to pretend to listen to what anyone else says during stand up while I wait for my turn to speak, back to back meetings, try to get some actual code written over lunch, some more meetings, pick up kids from school, try to get some code done in the evening, go to bed exhausted
My day:
Bike 30 minutes to work, eat free breakfast, go to some meetings, hit the free gym during lunch, unless it's Friday cause we get free lunch on Fridays, Tuesdays we have a personal trainer, Have another useless meeting, Maybe get some code in before leaving. Some days I wonder why they hire us to begin with. They can't possibly make money
@@timonix2 All the work is done by a single autistic guy, who has been programming since the 80ies. You guys and the workplace just exist to enrich his environment.
@@timonix2 "Quarterly objectives were significantly exceeded. Our Human Resources grew by 30% year-to-date and is indicative of a positive outlook for the subsequent quarters."
"An MBA grad is the natural enemy of the software engineer."
As a software developer myself, TRUUUUUUUUUUUUUUUUUUUUUUUUE!
Thank you for saying that, out loud, for the world to hear.
Engineers build stuff, and make it work. That's what they do, no matter how obscured that goal may be.
Everybody else, it seems, "makes plans" (and meetings about plans, and plans for plans (seriously)).
"Making plans" is definitely "work". But are they useful?
In my experience, "plans" (including design, architecture, and especially 'schedules') are almost always made by non-technical folks, and certainly without communicating with the technical folks in any way. So they're wrong, usually hilariously wrong.
I've noticed that such folks are all about making and remaking plans - but are absolutely resistant to using any past experience in creating these plans. They'll make a whole new plan in a heartbeat, but will never consider looking back at previouus plans, to try to learn something. It just isn't done. Hence same mistakes, over and over and over.
Engineers sigh, look at the new plan to see if it affects them, or the existing work, or the project in any way. Usually they don't. If they don't, the engineers ignore the plan and keep doing what they're doing.
The MBA is the natural enemy of all engineers. I am a field service engineer for semiconductor fab equipment. I have worked places where idiot MBAs had metrics to measure our productivity based on how much of our time was utilized.
Look, if I was the best field service engineer in the world, I'd spend most of my time drinking coffee, because I would prevent problems in 10 minutes instead of fixing them for an hour, before the tools went down unexpectedly. You DON'T WANT FIELD SERVICE ENGINEERS TO LOOK BUSY. That means your equipment ISN'T WORKING.
Clearly if the engineers wore suits and spent all day writing 3 emails and playing golf are the real backbone of the economy
an MBA grad is the natural enemy of shit getting done since all they wanna do all day is talk about spoons and tshirts and some weird points while sitting in a standup meeting
English is not my first language. What is MBA? Master of Business Administration? Management Business Administration? From the context of the video it sounds like Alberta was talking about a economy/business related "study".
I never understood why these studies care about lines of code when many programming languages could all be written in one line.
the wining strategy will be to do a lot of redundant code just to make the ceo happy
It's assuming a formatter/coding standard which makes sense.
It's the quantitative fallacy. People mistakenly believe that what matters can be measured and what can't be measured doesn't matter. There's also its close cousin, scientific management, which persists despite being thoroughly debunked.
As an SE with 40+ years under my belt, I totally agree! No notes! Keep up the great content!
thank you! 🙏
I really liked hearing what you had to say. I’m an Electrical Engineer who also writes some code. They really shouldn’t look at non-software engineer code quality or we would all be gone!
It's the tech industry's version of complaining about employees having too many bathroom breaks.
I love that reminds me of my father who was senior editor for a major newspaper, who got one day a call from his boss that he does too much journalism, and he shouldn't do that because they don't pay him for that.
They rather have him do nothing than work as a simple journalist, instead he done his doctorate on mostly company time. It makes sense because as senior members for example are responsible for taking up the slack when disruption happens. If everyone works at 100% capacity then the organization has zero resiliency.
The one line changes are usually the crazy hard to find bugs that take days of debugging to hunt down, these people are delusional if they think code quantity == better
Everyone sees the one line, no one sees the megabytes of logs you pour through to isolate that one line...
Exactly.
The crazies "one line code change" I made came about after a freaking week of debugging. It wasn¨t a true one line code change though, since in the process of debugging I had also added a bunch of comments, all to help with the analysis needed to do the debugging. What was the change? Just a simple off by one error. What made it hard was that it was happening in the middle of complicated custom multi-stage recursive algorithm that was hyper optimized. We had to draw a ton of diagrams out for what was to be expected for each freaking stage of the algorithm and go through and try and figure out when something was not right, and making sure that our assumptions on what it should actually look like at each of those stages. I had multi-hour meetings where we just was pouring over the diagrams on a blackboard and trying to poke holes in our possible assumptions on what each stage would like like and whether we should split it up differently.
On the bright side, after that hellish debugging, any bug that takes less than a day to solve feels reasonably quick.
Yeah like these people don't realize that actually the less you write the better, imagine the amount of tech debt you can acquire by writing redundant, unoptimised code. If I want many lines of code I could just copy paste the same function and rewrite some minor things inside 100 times instead of making it a generic function that can be applied to many use cases
Also, many of them may be the junior devs being assigned the minor bugs someone has to deal with.
These reports pop up when management is too ignorant about what their employees actually do.
"ghost managers" is definitely the phrase that hammered home to me that point here is to deny the personhood of the people who actually do the work alltogether
"An MBA grad is the natural enemy of the software engineer"
This has big "Have everyone print out all their git commits so we can get rid of the least productive programmers" energy
An MBA is the natural enemy of society writ large.
Normally, showing your code online would be a pretty good way to lose your job. If anyone ever saw it. But like you said, it wouldn't go viral, no one would see it.
"How can you fire me for leaking company secrets, I literally got 0 views!" 😂
EXACTLY! I've seen people get fired for posting snippets of proprietary code on Stack Overflow. Most organizations are pretty clear about "do not film little videos here and do not talk about your work on social media."
While(water.sparklyness < config.sparkeltarget && container.pressure < config.thatsdangerous){sparklegenerator.process(water);}
Noooooooo!
You leaked out company secrets! 😭
If you are gonna make a video like that, you need to have it checked by the company if they want anything removed.
@@autohmae yep, 100%!
"9.5% of engineers dont work" - a guy who seemingly has no idea wtf engineers actually do. We dont whip up a completely new piece of software every day. You know what, yes, lets measure productiveness by quantity of code, then we will all just add comments and you will wonder why nothing ever changes about the apps you rely on.
It cost $1 for me to make that 1 line change, the rest of my salary is from the 15 years of experience it took to know which line to change and to be the kind of person you can trust to change it.
(paraphrased from an old story)
When the internet IS a series of pipes, it seems pretty apt to apt a joke about a plumber (at least the original version of this joke I heard was about a plumber)
Anyone who's ever dealt with a 'mature' build pipeline knows what those are: I can't build/release from my machine so i have to commit every step in a larger change, or "oh the person who originally wrote this can't spell/doesn't follow the convention"
This
2:26 Guys she's just jealous she doesn't want to admit that her sparkling water company doesn't have the same perks as the other sparkling water companies.
As a tech lead; yes all of this. For very large parts of my career I've primarily written code to provide examples to juniors to unblock them, and commit very little myself. I'm paid to figure out what needs changing, how to do it safely, etc. not to make the changes myself. The main complaint I hear from senior engineers and above is they don't get to write code any more because other things need their time, this guy has just rediscovered things we've all been saying and drawn a terrible conclusion.
This. 100%. Same boat. I'am actually holding myself back from being promoted just to hang to that small scrap of code I still get to write.
“I take the specs from the customers and give them to the engineers…”
“You physically take the specs from the customers?”
“Well…no… my secretary does that….”
So you are one of those managers that wasn’t a good coder. Provided good examples? Ok, glad you know how to use Google.
@@glee21012What makes you think they're a bad coder?
He's an MBA. Terrible conditions are his stock in trade.
Nothing screams "lazy management" more than the idea of measuring developer productivity based on the number of lines of code.
2:20 Also, I don't need to be a software engineer to know that livestreaming their actual work would probably get most corporate devs fired. There's a lot of closed-source code out there.
Would be a shame if the entire SRE / Ops department got laid off. Oh...what is that ? An outage ? A security update ? AWS updated their service and broke the website ?
Good luck solving that.
If someone asked me if my primary job was writing code, they would be met with the most pained laugh they've ever heard. My *job description* is writing code. My primary jobs include:
researching existing code
meeting with stakeholders about what they want
meeting with stakeholders about what other stakeholders want
meeting with stakeholders about what they ACTUALLY want because they don't want what they said they wanted
teaching juniors how to work with the codebase
teaching managers our jobs are
That is so true!
Coding is not that hard, about 80% of the people out there would be able to code.
The hard part about the job is understanding the needs of the customer.
There are so many memes about this topic!
"meeting with stakeholders about what they ACTUALLY want because they don't want what they said they wanted"
I felt that
MBAs have been trying to get rid of costly software engineers since at least the 80s, but no low-code, no-code, or LLM based solution will ever replace us for exactly the reasons you outline. Software engineers have to navigate both human _and_ technical challenges, and addressing both together is the real value that we bring
That's until actual AGI, which by defintition can replace any mental job (and any job once robots get good enough)
Sometimes I feel like a .1x engineer with how many meetings I'm in to talk about doing work instead of just doing work.
NASA writes some of the best code on the planet BECAUSE they spend two years talking about and writing up documents on what they're going to code before coding it. Because when your computer is orbiting Saturn there's no on-site service.
It's one thing to have Design meetings, it's another to have meetings about having design meetings @@dtw8446
@dtw8446 Most software engineering shops aren’t making aerospace-grade software, and those meetings (actual planning meetings) aren’t the ones that the comment you’re replying to is talking about (daily standups and other “status update” meetings)
@@dtw8446 We ain't writing code for space ships but even if we were the meetings I'm talking about wouldn't keep anything space worthy. It's literally opening tickets to cover multiple discoveries for 10 minute tasks. Then a 5 meetings about that 10 minute task where the same questions are answered over and over again. It's endless bureaucracy for the sake of bureaucracy.
Goodhart’s law: a metric becomes useless when it becomes targeted a priori.
That sounds bad. Let's offer a bonus to anyone who identifies a metric that has become a target.
I wonder why we never see the articles about ghost hr or ghost mba's, must be working too hard.
Ghost executives
8:42 And yet, with post-COVID work from home + GPT-4 level LLMs coming out to accelerate writing, documentation and communication tasks, I can certify there's a lot of "ghost" managers now too. Should they be laid off? Absolutely not! If any worker, top to bottom, figured out how to axe 80% of their workload through WFH convenience and AI, we should consider that a step towards post-scarcity personal empowerment, not an occasion to put back money in shareholder pockets!
Criticisms of capitalism aside, I'd like to see these managers become contributing members of society rather than having decision making authority to rain down misery on the lives of innocent people.
Dear Alberta, Thanks so so much for bringing attention to people's livelihood, legal status, etc. that that individual simply did not care. The greed that is companies and managers are never the problem as long as I benefit from them and it is all the hard workers that are the problem is very upsetting.
I searched him and he himself is an immigrant came based on a student visa. Just why? Clearly he knows what is at stake. Given the political climate. As you said, Alberta, the terms he used ("ghost" etc.) is for attention. Also, as you said there seems no other paper. It seems he just started to publish.
We need to protect and care for each other not throwing under the bus.
This is why it's so important to distinguish between "coding" and "programming". The great majority of the work of a SW developer is in _solving the problem_ , i.e. figuring out *how* to do it---deriving an algorithmic solution---and designing it. Coding it is the last and least important part of the work. That's why measuring productivity of a programmer by quantities like lines of code or time spent behind the keyboard is extremely stupid. I do not put my ideas about the problem in a drawer when I "leave the office"... And you still meet a lot of managers, even people who supposedly should understand SW development (like "agile coaches") who suggest and promote exactly that. Guess who isn't their employee any more... ;-)
Once I chased a memory leak for 3 weeks only to commit ONE change on a boolean value in a DBus call (the sent message was never freed, useful when you malloc it by hand or even allocated statically).
Not to mention the time spent to find a reliable tool, given valgrind would not have compiled on the SH4 based board I was working on.
Or chasing and fixing that damn race condition.
Yep. I implemented 90% of my system using event sourcing to avoid race conditions. Naturally I spent 90% of my time hunting down race conditions in the other 10%.
Even if valgrind compiled and ran, it would most likely emulate an x86 machine, so it wouldn’t be useful. In my case it was armv4 before valgrind gained proper support for that. I was very impressed with myself for getting it to build and run, the people in my team that had requested valgrind weren’t :)
@@KoenKooi haha maybe, I didn't reach that point anyways.
I ended up by hooking all calls to malloc/free & new/delete (not my code, but from a genius that happened to be a colleague of mine).
Unsure if instrumented processes where LD_PRELOADed ou recompiled, but the output was a PITA even with python script to preprocess it :(
I’ve worked with 0.1x developers, and I’ve seen devs getting axed in mass layoffs (and I’m one of them). In my experience these two groups have no correlation.
In my experience, mass layoffs fire less necessary or less profitable groups of devs, but that not always has to do with devs individual performance, it often has to do with what useless project idea managers decided to put those devs (0.1x or 10x) on.
When I got laid off as an example, company fired all full stack web devs because they couldn’t get enough client projects that needed our services, but they kept all rust crypto developers because they had one big client that needed them. A few months later this one client closed their contract, and now those devs were laid off too. It had nothing to do with individual performance
So true and that’s one of the bad things of software engineering. You can for sure be blamed if something breaks but on the other end, it’s usually the product people who get the praise if a feature performs really well. And no matter how great you are at your job, if you have to build something that users won’t like, that won’t look great on you.
Or how expensive it is to run the branch office they're all in.
The MBA is the preferred degree for glue-eaters with familial wealth. As a general rule, I really don't trust anything an MBA has to say unless they can demonstrate basic competence in whatever they're talking about. This generally does not happen.
when a MBA hears that the dev team is developing something they isntantly feel like they need to be doing something at all times or they aren't working and thus they proceed to fuck with every single detail available to them and in the process slow everything down and fuck up the product so it's delivered wrong and late
"The first thing we do, let's kill all the MBAs." -modern Shakespeare
I believe that 100% of engineers should leave places like facebook or amazon.
As a software engineer who worked in industry more than 8 years, I obliged to say - “Coding is the last thing that skilled SE will do”.
As someone who works in big tech this is 100% true for people who I work with directly. There are people who work too much and people who don’t work at all. I’ve been both. You’re giving the benefit of the doubt to these “day in the life” influencers who show off doing nothing.
I was once flown to Europe last minute to identify and fix a software bug, the fix boiled down to multiplying one thing by -1. Customer was happy bug was fixed and ok with what it cost.
Multiplying one number by -1: $1
The expertise to know where and how to make that change, and test that it is correct: $10k
Having managers that understand that math: Priceless.
On the behest of a large management consultant company mine implemented an engineer performance monitoring tool based on lines of code checked in. I noticed many engineers hard-coding items that should of been config tables as it resulted in lots of needless lines of code (among other far worse practices), great for their 'performance kpi'.
Performance line went up......then again so did all the defects as our codebase became a nightmare.....It now takes 5 times longer to deliver features. So we have hired another consultancy firm to transform our ways of working and get things back on track. I am sure this time it will be different....
These MBA's / Consultants are the enemy of productivity, not it's savior.....
I was watching some videos on a similar topic earlier today, a video of a girl showing a day in the work of working at Google. And they showed all those perks and fancy stuff as well as meeting time and coding time. The amount of people who said things along the lines of "meetings don't count as real work, she wrote like one line and worked for 5 minutes they should fire her" was disturbing.
They watch a video of a girl eating a salad and say she's bad at C++ like where are you drawing this conclusion from 🥲
I wonder how much if any of this is also inspired by younger startup minded people who are used to move fast and break things environments where they are trying to build there hackathon app and publish it as fast as possible, working on small code bases on small teams. I feel like as codebases get larger and responsibilities get more real meetings become more of a thing.
@@SimplyWondering I spent a year isolating out a crash that only affected clients using high-definition monitors and another year to get the changes implemented. The novel of JIRAs and the legion of meetings were a thing.
Whenever meeting aren't real work, it's always the managers' fault.
@@albertatechOf course she is bad at C++. Everyone is bad at C++, especially people who think they are good at it. She is probably good at her job though.
This is the reason I hate the "lines of code" metric.
We used to have a "gamification page" where everyone's commit frequency (along with lines changed) was put on display for everyone.
Of course this led to people getting "you're underperforming" talks. It wasn't until the most senior devs (who obviously have less code changes than your average intern) complained that the page was discontinued.
Performance is a team dynamic. I have on days and I have off days. Sometimes I kick off after six hours, sometimes I'm here for 12. As long as my team is meeting our deadlines you shouldn't be concerned with how much code, how many commits, how many PRs we're reviewing.
The other engineers will absolutely tell you if someone is under-performing on the team (and it'll still take management 10 months to get rid of them ).
I've become a bit of a specialist in one-line fixes for bugs that take days or weeks to track down. The old joke about "turning a screw: $1, knowing which screw to turn: $9,999" is so accurate. It's incredibly satisfying to finally figure it out and get to be the hero by writing a single-line diff. On rare occasions it's even a single-character fix.
This, that thing about the single character change was so revealing that this person had no coding experience. There have been so many bug fixes that are changing < to
Can verify. That one character 🙈
A one line code change often suffices to get a program from failing under specific circumstances to always working. Make sure certain variables aren't already set, deactivate active environments, don't rely on Linux or Windows folder structure, make intermediate directories, ... All can cost programmers days to figure out where the issue is. So those one line fixes may save many people many days of work.
10% of all employees do nothing. Period
More like 50%
I witnessed a 6 month noshow who ended up leaving for a management role. And another 6 months no-resulter where nothing happened to the no-resulter
I've been a developer for decades. I've dealt with a LOT more managers, business analysts, and marketers who productively are "ghosts" than I have ghost engineers.
In the same paper 89% of mba's do absolutely nothing. Maybe we need to spread that info.
And the remaining 11% of MBAs are actively undermining productivity.
Gee, it's too bad companies don't do twice annual performance reviews that incorporate coworker, manager and customer feedback. And it's *really* too bad that there are no systems out there for engineers to track their work and measure their impact on customer deliverables...
In my experience, 10% sounds awfully low. There's a lot of engineers that just aren't good. I've worked with some brilliant people and I've worked with some useless people. As someone who sometimes hires engineers, more than half of applicants can't write a CS 101 program. I don't even conduct interviews anymore. I just ask applicants to write a very simple program. It's not just engineers, to suggest that 10% of any occupation is composed of useless workers is exceedingly plausible.
Right? Like the defensiveness here is kinda baffling.. Only 10%!!? would have been my spin on it. Maybe you can't cause you don't have the data for other jobs?
Hey! Found your videos a month or two ago and my only complaint is i wish there was more long form content ! Its so refreshing to see some developer opinions that are based a bit more in reality and lived experience then what you normally find here on youtube/social media. Keep up the awesome work!
also this spoke to my soul because i just recently had a random story dropped on me and was told it was a top priority from management that couldn't wait until the following week.... took me like two hours to write and test... took six days for pr to get approved and management to hit the button to approve the change SMH
Thank you, I'm so glad this resonates! :)
The 10% of developers who do nothing are more productive than the 50% who produce code that is counter productive.
Should also be pointed out that moving 1000 lines of code to a different part of the repo still counts as "writing" 1K lines according to most change trackers. A few months ago I had a project manager call me in a panic demanding to know why I had pushed 5,000 lines of code to main without any testing, and it took twenty minutes to convince him that it was just me moving his fully tested function to the file that actually uses it to prevent import shenanigans.
At least he had a legitilate concern, many would have thought they could lay off everyone else, give you all the work and pocket a huge bonus.
Yeah, code checkins, reviews, issue activity won't show who is doing what, at all. Somehow team members don't know who is "doing nothing". Somehow managers don't know who is not working. Naturally a random journalist knows what's actually happening better than the folks actually working.
Nice coverage on a lame, ludicrous "study". Thanks for your time on this.
People think programming is changing oil in a car... but it's more like trying to change the oil while the car is speeding down the highway, the manual is written in kanji, and every five minutes someone replaces the car with a spaceship.
So what you're saying is.... Japanese alien mechanics are the real 10x engineers?
You got a manual? I’m jealous.
It’s more like “engine is running slow, don’t know why” and thirty minutes later you find out a little gunk is on the throttle body and impeding air flow by 3%
This video was very interesting, would definitely watch more long-form content from this channel (though the short-form skits are incredible)!
I predict you won’t need to make a tearful apology video. Your take is 100% spot on.
I think another reason software engineers get picked on is that nobody else really understands how complex software development is and what’s involved.
it's not just about software development, most people don't understand how complex the other fields are
apart from physically demanding workers like janitors, waiters and other service people it's hard to see where "we need to replace $10 gasket, it's gonna be $510" comes from
and even with waiters the part you see is "they bring me food"
the part you don't see is "staying late to clean shit and close the register" and much more things i don't know about
One of the main reasons I left big tech to join a smaller, 100-person company was the disconnect between management and the actual contributors. In larger organizations, non-technical managers often struggle to identify who’s truly doing the work. The so-called “0.1x engineers” always seem to dominate discussions with endless proposals and ideas, but it’s someone else who has to implement them. Ironically, managers often perceive this as being proactive.
"One line changes can often be the most important changes."
Like that one line fix that was the result of a two-week debug effort chasing down an intermittent failure? Yup, been there.
Or like that one line change that made 8.4 Million computers continually BSOD until the file was deleted in Safe Mode.
Loved this longer video.
If we are going to be measured by lines of code written, I might as well forget the DRY principle and everything I learned in Clean Code.
I’ve been on TH-cam for so long but honestly, you’ve become my favorite content creator on this platform. You deserve way more subscribers. Your content not only educates me on the world of software engineering but also makes me feel better when I’m having a rough day with your comedy. You’ve honestly inspired me to research more about software engineering in-general, and you’ve definitely changed my life for the better.
Also pls do more long-form content😭😭😭
Ahhh thank you this is so kind I really appreciate it :,)
7:17 they should measure executives. They get the most money and I think they do the least amount of productive work.
I flip flop between 10x engineer and 0.1x engineer. Basically I procrastinate the actual coding while thinking about the implementation options over several days of keeping up appearances. Then when crunch time hits I knock it out in speed mode because all the complex issues are already solved before I started.
i think thats a lot of us tbh, my whole team is like this, we go in spurts of doing a months worth of work in a week and then being burned out. as long shit gets done by deadline, everything's good
That's called "dsign", not procastination ^^
@@_stix If you or your team weren't involved in negotiating the deadline, or the details of the change weren't known at that time, that point in time isn't a deadline. If anything, the seniority of the person who chose the target date is *inversely* proportional to how much ass-busting you should do to hit it, because they don't understand the detail of your work and they won't notice or care about your extra effort.
"When will you be releasing this change into production?" "When it's ready."
The only exceptions should be regulatory, legal, or contractual, or if you're not at risk of burnout, self-imposed (or agreed with collaborators) to finish something you personally care about before you (or your collaborators) take a holiday, move roles or leave the company.
As an SWE with 10 years in the same workplace, I have to say I partially disagree. To be clear, most of what you said is correct - What I'm getting at is, IMO there are employees who consistently bring MUCH less value to the workplace, just like there are those who consistently bring more value. Sure, there are built-in processes to identify and remove low performers (e.g. yearly performance reviews). But those processes are not perfect, and there are employees who definitely "slip between the cracks" and continue to do jack shit for most of the day.
I work in a big corporate, and due to management oversight it can be ridiculously easy to get away with doing the very bare minimum and sort of "padding your work" to make it look like reasonable output per-day when in reality you spent 7 hours on social media and 1 hour coding. I used to do that myself, for weeks at a time - especially when I didn't have clear deadlines for anything. I suspect that in "leaner" companies this would be much harder.
Is it 10% of devs? IDK. A less sensationalist headline that is closer to reality would be "small % of devs get by with doing basically nothing and are a waste of company resources." But I feel like that is kinda obvious anyway.
Sometimes it can even be hard to explain to your boss how much work something takes to do...
I learned the hard way. I bashed out a mockup of a feature I wanted to implemented and gave it a frontend in a framework I'm comfortable with over a weekend. Tough trying to explain just how long it's going to take to implement it in our actual codebase
@@TecHippy "It's done and it works. Why do you think it needs more work?" said suspiciously by our "team lead" after I did similar.
I'm just so thankful that you took the time to make this video. It's so overwhelming to try and combat this type of bullshit to people who don't know what software engineers do
I spent hours this week in meetings for a "1-line change". Sure the change enables a feature that cannot leak before the official announcement, and needs multiple teams to be ready, but those are irrelevant details.
When would renaming a variable ever be a one line code change?
One of the problems is calling hs "programmers". We are software engineers. Software engineers research, plan, and then implement. Saying we're "programmers" makes it seem like all we are supposed to do is implement, when a lot of it is the research and planning. But I wouldn't expect an MBa to know -anything- that
Um. I'm going to take exception to that. Sorry. I'm a computer programmer. I have yet to hear a definition of software engineer that I can make sense of. Maybe I'm just not smart enough to understand, but I've known and worked for engineers most of my life and it's not clear to me that software development is, or ever can be an engineering discipline.
@@quintrankid8045 So you are stamping punchcards for the computer then (not acutally figure out where the holes go, just usinging the stamping machine)? Engineering is excatly what it sais, design of software to work as good as possible, just like a aironautic engineer optimises the workings of a plain for a problem.
@@ameier5570 That's not the definition of engineer I was taught when I was a young 'un. But I suppose nowadays we can make words mean whatever we want. Optimizes is an interesting word. When you write software what do you optimize for?
@@quintrankid8045 Engineer = "a person who designs, builds, or maintains engines, machines, or structures". at least that is what google sais and yes technically it doesent involfe software in that definition.
And for what you optimise depends on the case, sometimes speed is more importand then maintainability sometimes you have to optimise for low latency sometimes you have to structure it a sertain way, the list goes on. The answer is as almoste everywhere in IT: "It depends". But i asume you are a expierenced IT person so i have to assume you know that already, so why do you try to test people?
@@ameier5570 From my view that definition doesn't include the mechanical engineers who do fluids or chemical engineers either.
I'm not testing, I like to know how people think about things.
it's pretty easy to see if someone isn't doing anything and your manager knows what you're doing anyway. The article is ridiculous
I really like these longer videos a lot better than the short ones.
Ah thanks, glad you enjoy! :)
I enjoy both formats!
Shorts are like snacks. They're cool and all, but you can reach the point of having consumed too much, and yet still need the satisfaction of a proper meal
I have pretty bad ADHD but I love watching multi-hour YT videos from channels like:
- Well There's Your Problem (a podcast about engineering disasters, with slides)
- Drachinifel (a naval history channel by a qualified engineer, his Dry Dock Q&A videos run long, especially the monthly Patreon-questions-only episodes. Record is over 5h iirc)
- Perun (an Australian who studied historical war economics at university, now works as an analyst in the military industrial complex down under hence the pseudonym, pivoted from a gaming channel to weekly PowerPoint presentations about war, logistics, supply chains... Very funny, and he's interviewed and been cited by known experts, and generals retired David Patreus and Ben Hodges)
- C&Rsenal (the history of firearms, one gun or family of guns at a time. Covers the designer's background, how the design built on prior art, its testing, adoption, service history, a practical demonstration and a review of its performance and ergonomics)
@@EmyrDerfel The vertical format of the shorts doesn't look good on a computer screen.
I once spent 4 months on a fault, researching, debuging, meeting with SMEs and stakeholders. It also needed detailed system knowledge.
In the end I changed two lines of code and it saved the company millions in less than a year. It was our most beneficial software change ever to date.
loads of bug fixes are also 1 line changes that take multiple hours and effort
Nothings wrong with not doing a lot of “work” but do you deserve to not have a job because of that? I don’t think so
One line code changes may require literally weeks of testing ...
24 lines of code can produce a wow but may require tons of thought
I love that you add some clarity and context to the world of tech. Keep making great content!!
Omg, like managers are the worst investment ever, they produce zero lines of code, and are always giving their work to everyone else. What even do they do? How is telling Bob the engineer to work on a feature worth their salary? Anybody could tell Bob the engineer to work on that feature... /s
As a software engineer, I feel lots of this. You're a great engineer, and half the job is staying sane. People don't get that the job isn't just code.
I work in big tech. There are lots of engineers who don't write a lot of code. We even have silly names for them. I think we call them "managers" and "tech leads".
In Brazil I've heard the term "programador de word" (MS Word programmer) meaning someone who is in a managerial or like high level analyst role
For me, it's fine if the manager or tech lead for the engineering team doesn't write a lot of code, but if they don't know how to code, it's a real problem imho. And believe me, I've already seen some of these cases. 🥲
Changing the one line of code causing the bug: 1 minute. Finding the one line of code causing the bug: 10 hours.
Wow. It's quite a stretch to imagine that if someone doesn't show EVERY part of their job, then they must not do those parts they don't show.
Thank you for properly explaining that someone who finds and fixes a tiny thing might be as or more productive than people who do tons of lines of code. It reminds me of this quote from fortune(6):
A novice was trying to fix a broken Lisp machine by turning the power
off and on. Knight, seeing what the student was doing spoke sternly:
"You can not fix a machine by just power-cycling it with no
understanding of what is going wrong." Knight turned the machine off
and on. The machine worked.
The novice is the person with the MBA pretending to understand programming.
Less than 50% of my time is writing code as a senior engineer
Sounds to me like, “Lefts fire the people we don’t have enough management skill to manage properly.” What a cop-out.
I like more thought out content and it's interesting to see the opinion of someone else in tech, please keep the long form coming
I'd probably get counted in that category. A commit of mine gets merged once every ~6 months. However, each of those commits usually represent months of prototyping, experimentation, and other R&D type stuff. Different types of work require people to work at different paces
Alberta, I've come across your content recently through shorts and it's quite nice. This is the first longer video of yours that I've seen and I'm glad i have.
As an engineer, I've come across some ridiculous takes after this article got traction and it's not only refreshing but absolutely necessary to have people like yourself questioning the focus of this article. Workers are not the problem, much to the contrary. This whole thing seems like yet another attack on this rare section of the working class that have achieved a reasonable level of compensation.
Anw, great content. Cheers
Thank you, and I completely agree!
I wish my fellow MBAs would stop giving us a bad name pretty pretty please
Regarding sloc counting...
I am "senior" engineer, and quite often one younger padawan is asking me for help. And most of the time, after review, line count is getting much lower, with resulting code being much more readable and doing exactly the same as initially intended. More code != better code.
We don't have such metrics in our company, but looking over commits - I have "windows" without commits, but not because I didn't work, it is just that reading requirements, doing research - doesn't go into commits. And even if I code something - it might be that the changes I made are not yet ready to be committed, as I prefer to smoke test before that. For some reason I even feel uncomfortable to change the code I recently committed, as someone would think that I couldn't get it right from the first try. But still, I am happy that our company doesn't analyze quantity of code, top priority - to implement features before ETA, and to have less bugs.
3:55 i think there was a lot of cuts here and it made it a bit difficult to keep pace with you speaking, still really good video!!! love the longer ones
thanks for the feedback, i have a tendency to cut out every single pause / breath I take 😅
@albertatech always make sure to drink a good amount of water before recording and to take a deep breath so you can speak it all in one take :)
@@albertatech and I still watch it on 2x!😅
Sometimes, I wish devs would do nothing. This giant machine doesn't lack speed, it lacks manoeveravility.
Btw, I can just second the notion that developing is mostly NOT about coding. Writing it down is mostly trivial. Understanding and deciding the right thing is the hard part.