I once reviewed code for a company that got purchased. I took less than a few hours to reach conclusion. There were 7 developers and in 2 months only one was writing code. The entire team but that one developer was fired. Twitter has grown a reputation for being slow and a rest and vest haven. Won't be surprised if they are looking for people not writing code.
On a different note, If you're in a large org and all you are doing is fixing bugs, you are doing yourself a disservice and so is the org in the way they are treating you. Unless you are the original author of that code. When people don't fix their own bugs, they tend to repeat it in other places. When people tend to fix code they didn't write nor have the proper context on why the code was written like that, they tend to turn it into a mess. IMHO, Developers should be writing new code and maintaining their own code. Never reward developers by giving them more new code and stopping them from maintenance.
> I once reviewed code for a company that got purchased. I took less than a few hours to reach conclusion. There were 7 developers and in 2 months only one was writing code. The entire team but that one developer was fired. Twitter has grown a reputation for being slow and a rest and vest haven. Won't be surprised if they are looking for people not writing code.
I ran across some developers (in multiple orgs over the years) that would produce large amount of almost purposefully unmaintainable code. Yes, they were “productive”, and no, the stuff they produced made no difference and was a waste (both features wise and code wise since). 100% of these codebases turned out to be unsalvageable and were rewritten. It just would usually take orgs many months, usually after such developers leave to realize the complete and utter waste they left.
Not saying there are no slackers, it’s just productive devs are not necessarily those that produce the most of code.
“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.”
― John Ousterhout, A Philosophy of Software Design
I remember reading somewhere people can be broken down into 3 types. It applies in programming as well as in a restaurant kitchen or your family's garage cleanup.
*I'm probably remembering everything wrong but it was something like:
Cowboy: move fast and break things style. Sorta what you mentioned above.
Duct tape: most people are a form of this. Work on something just long enough to get it working but it's not beautiful and not prepared for the future or edge cases.
Professor: these get very little done because of the amount of planning put in and tend to over think most things. But almost never have to come back to a job since it's done properly and to completion.
Any team without a blend or with too many cowboys or professors is going to have a tough time.
That's why I refuse to touch code made by these tactical tornado. It's simple, you'll get all the blame, and none of the recognition. Anyone who is in that situation: Don't it even if it means you'll get fired. You'll get fired anyway.
The only exception is, if management come to understand what went wrong there and how it should be done. The chances of that are very slim, however.
Peer reviews catch tactical changes that are strategically poor. There are times when it won't get sign-off from reviews. In other times, when it gets merged, at least it is documented that the solution is tactical, people know it, and it was rationalized by the team. A plan may even be put in place to revisit the subject and do a proper job; there could be concrete ticket for that.
Reviews also slow things down. You can't move quite as fast and break as many things if everything goes through a review pipeline.
Test-oriented development helps. Sometimes people find it easier to develop a tactical solution that somehow gets certain tests working and then refactor for strategy. They don't have to feel they have wasted time on the tactical solution because they get to reuse parts of it, and use it as a jig to guide the improved solution.
Ron Garret's space debugging story from NASA has an element of this. They had a custom language in Lisp which made certain guarantees, like deadlocks being impossible. But some coder went around it, possibly due to a tactical reason, using some lower level code outside of that paradigm.
Sometimes people aren't being tactical; they really don't understand the system fully to know that some obvious solution will hit a snag.
This lines up with my experience. The person making constant "tactical" changes looks super productive. But they just deferred the productivity cost. You end up continuing to deal with their fragile mess for the rest of the lifetime of the product.
I fully understand that there are circumstances where true tactical changes do make sense, but the tradeoffs should be considered up front.
The way to handle this, I believe, is to make sure that the bug reports resulting from the "tornado"'s work end up back in their own lap. Don't let someone else fix them, especially not someone on another team. It has to be done non-antagonistically, of course. But it's the only way to make it clear to both management and (more importantly) the dev themself that there is a tradeoff for speed.
LOC produced is a good example of what I call "negative" metric: high value does not mean much, but low value is a good indication that something is up.
As a manager, I won't care that dev A produces 2k vs dev B produced 4k. But if I see dev C would produced only 30 loc over say a quarter, something is most likely off.
At some point, the curve definitely bends negative. I used to work on a team adjacent to one of the most "productive" programmers at G by that metric.
My team, and at least 4 other surrounding teams, had one full-time SWE cleaning up after him. He would go around making changes assuming things that he thought were safe and breaking tests, then his manager would argue with you that because you didn't make a promise that what he did wasn't safe, you have to fix the test breakage.
Yes, there are large negative externalities to a certain type of engineers who write a lot of code of dubious quality. Even after ignoring all the trivial cases of "artificial code stuffing", etc.
I used to work in a very dysfunctional org where the main "architect" was writing lots of broken code that kinda works, and the 20+ people in the team around it would basically be full time in fire fighting mode. The architect was a very smart guy but ironically enough without any sense of architecture: his level of abstraction for network was pushing bytes through a pipe, and for loops for calculations.
That was similar to this guy - he was a good IC who ended up being over-promoted to an "architecture" role (L7). He didn't really know how to architect things, so he went for creating externalities while resurrecting old, dead projects that past people had designed for him.
In your career, how often have you seen good software engineers whose main contribution was deleting code ?
Please take my argument in good faith: I am not looking at evaluating people based on their added LOC. The context is at orgs where I have reason to believe some people are slacking off, and looking for people who do next to nothing.
That's much more common than people who magically make everyone more effective by only deleting code.
I've seen a few projects across different organizations where an old dev was bad at copying and pasting code and ignored DRY principles. The projects had almost no refactoring, and the primary goal of a new dev was cleaning up the redundancy to better map things out for better organization of the codebase.
I don't think anyone (sensible) thinks 'if someone only writes 30 lines of code per quarter, they should be immediately fired'. I think the point is more that if you have someone who's only written 30 lines of code, it's worth taking a look to see what they've been doing instead.
For sure there may be a thousand good reasons for it, but as a quick heuristic for 'who is worth having a quick check to see if we're getting the value out of them that we're paying them for?', I don't think it's irrational.
No, this ratio is unrealistic. Either you're making numbers up rather than describing a real situation, or yes you're far too slow for me to want to hire you.
There was a funny story I don't remember where... A manager was doing LOC as a metric, and they were required to count it. But an engineer refactored and put -1000. That was the last time they asked for it.
I'm finally working directly with one of these developers. Thankfully he is leaving next week on his own volition. My work load has doubled over the past several weeks due to rewriting most of his code. And needing to extensively vet code that he's still submitting. The worst part is that he's reasonably productive at producing lines and lines of code that barely function.
I am curious. Does your organization not use TDD ? How would the code be allowed to marge without running your test suite ?
In my experience, I have found it is more productive to coach and mentor developers to adapt TDD and DevOps practices than to vet their code. Instead of vetting their code, I would incorporate statistical code analysis and vulnerability analysis into the build system.
Mutation testing can help evaluate the quality of a test suite. The application code is automatically tweaked and tests run. If a mutant is not "killed," then additional tests may be needed.
> coach and mentor developers [rather than] vet their code.
How do you teach these things concretely without discussing specific code? How do you tell if the lessons are sticking without checking their future work?
Aside from that, neither TDD nor DevOps practices will get you idiomatic (relative to internally and externally) code, documentation, non-requirement performance worth a damn, test suites that are any good to begin with, etc. etc.. If you're running through a backlog of CRUD-ish features or whatever maybe those don't matter, though then I also wonder why the need for TDD instead of just a good CI pipeline.
Not enough. I'm trying to do this with our new code base, but it's difficult when I need to get everyone else on board. I'm trying to lead by example, but I feel like I'm also racing against other devs to get good feature work in before bad code gets in. The rest of the devs will simply copy what the existing code does instead of figuring how how to do something properly. Doubly frustrating that I don't have a senior title or pay, but am hiring and cleaning up after senior devs.
This is also a sign that code reviews are not working properly (either missing due to a team too small; or not enough time invested to do them properly; or people are not "free" enough to tell their coworker that their code is bad; or it was done too late, once there isn't enough time to fix it; etc).
Or code reviews are working fine but there are no long-term consequence for people whose code consistently takes 10x more revision after reviewing. (This is also a kind of organizational failure, but one where reprimanding the IC in question can still be the right response. But I also doubt a drive-by ad hoc external review of every person in the company is going to be the best approach to find this!)
> I once reviewed code for a company that got purchased. I took less than a few hours to reach conclusion. There were 7 developers and in 2 months only one was writing code. The entire team but that one developer was fired.
Larry Ellison famously once said "if you aren't a developer, and you aren't a salesman, then tell me real slow just what it is you do".
And yet we have people whose job is to help software getting deployed, infrastructures getting the timely upgrades, capacity planning, monitoring and alerting, honing their troubleshooting skills so when time comes to save your business they know how to do it and have the right tools not break in their face.
Yes, let's treat those tasks as less honourable than developers and enjoy the results
>> capacity planning, monitoring and alerting, honing their troubleshooting skills
> This is veering into made-up-job world.
Maybe if you're running a CRUD app on a single server in your basement.
But these are definitely core engineering competencies for any system large enough to experience regular and non-preventable failure. Hardware fails. Technician error happens. A litany of natural disasters from heats wave to flooding can impact a DC or the infrastructure within hundreds of miles of a DC. Load assumptions are violated. Etc. With a large enough footprint, these sorts of things happen often enough that robust monitoring, alerting, and planning are necessary. (Hell, just building a DC requires significant capacity planning, to say nothing of keeping the thing humming along happily.)
Either you're doing this work internally or you're paying AWS/GCP/Azure to do that work for you. In many cases a mix of both. But if you're large enough to need even a small data center, this work is being done by someone.
If you don't know about it, you're either small enough to run your business from a few servers or you're paying someone else a very nice premium to abstract away the details. (Or, most commonly, both.) But if you have any amount of scale, the work is being done by someone.
Anyways, this attitude is probably spot on and is why I expect Twitter to go from "stable if unexceptional business" to "can't even stay online" to "MySpace 2.0" within 10 years.
Twitter was not profitable last quarter. It rarely has turned a profit. How does an unprofitable business qualify as “stable if unexceptional?” I should think an unprofitable cash burn as long as Twitter’s should count as highly exceptional.
Twitters revenue been growing quite well though it’s clearly spiky. Spending isn’t really a question of what developers are doing that’s all about management.
These functions are mission critical, but if you can’t show how you’ve automated / created programmatic solutions in these domains then you are probably part of the problem.
> I’m saying that “ capacity planning” shouldn’t be someone’s entire job.
Capacity planning is everywhere in the real economy. In most sectors, any reasonably sized company will have entire departments and sometimes even divisions (eg, approximately everything in management of a large construction project is capacity planning of some sort or another). One of my first consulting gigs was with a small/small-medium sized resource extraction company, which had several people whose job was essentially 100% capacity planning/forecasting for various components of solid wood product supply chain. Basically anyone who wasn't either in the executive team, in the field, or selling was spending most of their time on capacity planning.
My very first job was with the corporate office at a regional supermarket chain where demand forecasting and figuring out warehousing/storage constraints (aka capacity planning) were their entire job.
In both cases, the profitability of the entire business relied on good capacity planning, full stop. Everything else was either par or total commodity.
Taking the economy as an aggregate, it's actually a fairly rare thing for capacity planning to be totally commodified in the way that hyper-scalars have done in software. Software shops that outsource anything non-soft to the massive army of operations folks at AWS/GCP/Azure are extreme outliers, not the norm, in terms of the real economy a a whole.
Yes DevOps and shift-left and whatnot. All those things do make sense (to some extent) but:
1. When developers own these aspects of the software operation lifecycle they do not produce the same amount of "code" and "features" that an old-school developer would be expected to have.
2. Even in the most utopic DevOps heaven scenario, there are still some people who will be drawn to do more "systemy" things and some developers who will actively resist at investing time at getting good and doing operations stuff. Getting rid of these people is an option of course; good luck.
Yeah sorry. The story here is how people at Twitter must prove their worth by printing the lines of code they wrote, so I erred on the side of that angle also for the Ellison quote even if I had no reason to do so.
> This is veering into made-up-job world. These people are getting fired. All these tasks can be done by developers.
Ah, the good old Google playbook. If you read their paper about how SRE came to be, it basically says: “we noticed there was friction between developers and system administrators so we fired all our system administrators and hired developers to do their job instead.” It doesn’t really make the job disappear however. It’s just a different way of approaching it.
You’re misunderstanding me slightly. I’d put systems administrators in the same category as developers, and I think so would Elon Musk and Larry Ellison.
But if someone’s entire job is “capacity planning”, they’re getting fired.
This is just the prelude to an apocryphal story. At the end of that story, Oracle stops innovating and becomes a legal and license auditing firm with sales and engineering departments bolted onto the side, slowing atrophying into the sunset.
That works for, say, trademark infringement lawsuits, where even the businesspeople doing the suing say it makes them feel dirty.
It does not work so well for someone who bought a company that made an open sourced language, and then sued another company that wrote its own version of that language, arguing that even the APIs were under copyright.
People leave jobs. If you're working at a company that's decades old, the people who did create the bug might have left the company 20 years ago.
I don't know for your job, but at mine code is supposed to stick to teams rather than people, so even if the people didn't leave the company, they probably changed teams and don't own the code anymore.
Hard agree. The only case where "You fix all your own bugs" makes sense is a small company or start-up... but it's also a bad idea. Every engineer should get up to speed on every feature until it is no longer feasible/reasonable to do so.
We intentionally cross-train and work bugs in "others code" (we do not assign code ownership, after I review and it is merged, it's is my code now, for as long as I work here lol).
I don't care about the products I work on. I don't own the product, I don't work for an NGO willing to change the world and the product would probably won't revolutionize the industry.
The product's only purpose is to make some people rich. And I don't care for it.
What I care about is being paid, learning, advancing my career and not being bored to death while I work.
So I do quality work because of that. I don't enjoy fixing bugs (some people do), so if I can avoid fixing bugs, I'm happier. I also try to ship as least bugs as possible and I test my code before pushing it. The code has to pass an QA cycle so I will fix my bugs if any. But if some bug is coming from production I'd rather pass on it and take on a feature instead.
Sure. But also if all you do is fix bugs, unless they are really hard and complex ones in occasionally new domains it's probably not the best career path.
As an example fixing trivial styling, dead links, documentation, flaky tests. Work that is important and has to be done, but not
something to drown yourself in. Sometimes it's also better to try to solve the root causes, like use css variables, introduce swagger or a more reliable test framework. You want the engineer who codes themselves out of the job of trivial tickets.
I agree with it. There a rare subspecies of developers who enjoy fixing bugs. The more rare and obscure, the better. Maybe they derive the same kind of pleasure as a police detective solving a hard case.
I do believe they should be princely rewarded and I would hope there would be more of these people as this will allow us the people who enjoy building concentrate on it.
I believe there was a thread on HN two days ago of a guy who enjoys fixing bugs asking how he can make a business out of it. Chapeau to him!
I agree, but I do think that's kind of an imaginary enemy. I don't know that anyone said "All I do exclusively all year is fix trivial bugs in hacky or minimal ways". Probably what anyone does is a bit of this, a bit of new code writing, and a bit of new feature stuff.
That's essentially what I do. Sometimes bugs are quite mentally demanding to resolve, but a couple weeks of that begins to get really draining, so I try and move onto something more on the implementation side for a bit.
But isn't having no bugs to begin with better then fixing them later?
The argument was that you'll have less bugs if you use these technologies after all.
And I have to agree wrt styling inconsistencies and css variables at least.
They're extremely good at standardizing design without getting in the way of the developer
Honest question - have you ever worked on a codebase with 0 bugs? I don't think that's feasibly. What you're asking for is an infallible god-like programmer.
You will always have bugs. The best engineers can solve the hardest bugs
It's feasible to create no bugs with formal specification and formal verification. For example, with Lean 4, one can add a proof for each array-access-by-index that the index is within the bound of the associated array. Every aspect of the codebase can be subject to formal proofs that are verified by the compiler. See also CompCert and Sel4.
CSS variables, test frameworks, are good tools for catching bugs -- but at the end of the day the goal is that the code should work and be easily maintainable. Best practices help you do that, but theres many instances of a code base full of bugs that has to be maintained and improved over time. Developers who turn up their nose at "fixing bugs" are of no use to a business. These ideas are great when starting a new codebase but thats not the situation a developer is going to be in most of the time in practice. And if you follow every best practice there will still be bugs that need to get fixed.
You're arguing with a straw man then. Their argument was that only solving bugs is an issue, because you should be taking preventative measures so they're occurring less frequently.
If the bugs are all your doing, I agree. But many times the developers working on a project are maintaining code that was written years ago before they even joined the company, by other devs that had totally different incentives.
＞ There were 7 developers and in 2 months only one was writing code.
I would suppose you were looking at many more signs and metric, but then you say it only took you a few hours, so perhaps not ?
I’d assume that dev wasn’t actually writing alone, and people had to discuss the design, talk with the PO/stakeholder, review the code, eventually QA it, manage the deployments etc. Perhaps that poor soul was doing everything alone…but really ?
I can readily think of a few people in my current company that are absolutely drowned by merge request reviews and technical design work, even as their title is just “developper”. I wouldn’t be surprised if they haven’t written a line in weeks, and perhaps one or two fixes in months. They are absolutely critical and I would laugh so hard if someone buying us just fired them because they couldn’t bother looking at other stuff than code written.
This is probably an extreme example, but it is no secret that the majority of people employed in an organization actually does barely anything of value. Price's law comes to mind.
I’d argue that’s a separate and more deeply rooted issue.
At some level of abstraction, most of the currently prosperous IT companies could be seen as barely producing anything of value, and our startup culture kinda goes in the same way (purely looking at the rate of success vs failures gives a grim picture regarding the amount of time dedicated to these failures).
We have many justifications for that, but at no point I’d see our field as being hyperfocused on only solely bringing actual value to the world.
PS: that’s not just our field of course, ad business comes right to my mind, but we probably have many other work field with very little ‘value’ when looked from a high enough perspective.
The way I see it, the current ridiculously high salaries of SWE, the easiness of it, how little so many seem to do valuable work, is in a big part due to inefficiencies in the system, due to novelty of SWE and how invisible it is.
In my field, mechanical engineering, we've had centuries of machine making. Margins are usually razor thin.
In software that's not the case. Subscriptions that should cost the customer cents per month or year, are costing 10-100x that. Margins are ridiculously high. But it's all so new and not intuitive, like a physical part, we just pay whatever.
Then the invisibility of code and difficulty of distinguishing from the outside what is well made and what isn't, enables.
In all my years working as MechE I've never seen anyone just slacking off. We're all always being pushed, working. I look some of the stories of SWE and it's ridiculous.
I think many SWE just rationalize their high salary as bringing more value to the world, which imo is not really true.
I once reviewed why colors were off in the MacOS version of LibreOffice. Not being all that familiar with the code, I spent days reading through the code. Then I idly looked up the kCGColorSpaceGenericGray and kCGColorSpaceGenericRGB in Apple's documentation, and realized they had been deprecated. Switched to the correct color space and suddenly all the tests passed.
Several dozen characters changed in the actual code. A number of ifdefs removed in the test code. Literally hours of wracking my brains as to the problem in unfamiliar code on a relatively unfamiliar platform.
Spending a few days to produce a short bugfix is normal. But in a full-time employment scenario, you might have a bug hunt like this every once in a while, but definitely not all the time, you’re also usually working on new features, so you do have some output to show.
Assuming that whoever wrote it in the first place is (1) Still employed, (2) Capable of fixing the bug and (3) Would never be told about the bug fixes you may be right.
That said, I think it does make sense if the goal is to (somewhat superficially) sort the employees into "probably keep", "review", "probably terminate" piles. And maybe with a good enough accuracy that that information can be directly acted on.
This is a inaccurate in my opinion. Obviously all developers should be writing code but in my experience there's usually about half new feature work and half maintenance. A lot of the maintenance is of projects written by people no longer at the company. I guess you're advocating for a policy of complete silo-ing where devs only ever work on what they wrote in the first place and no one can jump in and help other teams under any circumstance, but at least the companies I've worked at have not advocated for that policy
> When people tend to fix code they didn't write nor have the proper context on why the code was written like that, they tend to turn it into a mess
Try fixing your own code 3 months after you wrote it. You end up turning it into a mess too. To think code is something that stays in long term memory somehow is a flawed assumption. We should think of it as language, you say something to someone and a few hours later have 0 memory of how you phrased, the words you used and why you phrased it the way you did. Taking code so seriously ends up sucking the enjoyment out of programming and turns it into a boring office job that you clock in and out so just that you get a paycheck. Let's not create random rules that benefit no one in the long term.
To become a better programmer is a choice people have to make for themselves not dictated by a manager who probably became one because of their mundane prior coding role.
There is quality, quantity and then there is common sense. I have seen an entire new dependency system invented because the author did not like open source ones. It worked great for 10 years and then they left.
I also have seen a scenario where we killed a hundred thousand lines of code for concurrency by using standard libraries and a couple hundred lines for adapters
why do you need a code review for this ? It is easily scriptable w/ GH, and I would expect whatever system used by twitter to support this kind of basic functionalities.
While I wouldn't go chasing after programmers asking why they contribute so little I still think being able to quickly produce some sort of an insights dashboard can help decision making.
On a different note, If you're in a large org and all you are doing is fixing bugs, you are doing yourself a disservice and so is the org in the way they are treating you. Unless you are the original author of that code. When people don't fix their own bugs, they tend to repeat it in other places. When people tend to fix code they didn't write nor have the proper context on why the code was written like that, they tend to turn it into a mess. IMHO, Developers should be writing new code and maintaining their own code. Never reward developers by giving them more new code and stopping them from maintenance.