Less code is more readable. But absolute minimal amount of code can be unreadable.
Writing less complex code in lots of situations just means writing lots of code. Which is diametrically opposite to the original statement of less code being better.
At a nonprofit I work with, there was a series of web forms that volunteers had to go through in order to enter a bunch of data.
Volunteers have never liked this form, but it was at one point necessary to collect all this data. A decade after those forms were built, it was decided to finally spend some of our (all volunteer) engineering capacity to help streamline the process associate with those forms. So, a junior volunteer comes in, hears the groans about this form, and found out a bunch of this data was already stored in other tables (in the interim smartphones became a thing and customer intake went from completely free form to a self-service signup process). The volunteer writes a bunch of selenium code to pull data out of a few tables and use it to population about 80% of the form fields, leaving volunteers with only 20% of the original work!
Some time later the whole thing gets reviewed by an (again, volunteer) old hat staff who were around when the original form sequences was developed. Turns out we no longer needed those 20% of fields, and ofc we already had the data in the other 80%... so all the original form code was deleted,
So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context.
Bravo.
(And for those arguing that “but the least amount of lines is not necessarily best”, yes, of course, that can obscure logic; the point isn’t to flip the value of LOC as a metric, the point is to not treat it as a good metric).
... but in practice, I think you will find 0 overlap in raw lines of code produced between the top 10% developers and the bottom 10% developers. Especially at a notoriously unproductive organization like Twitter, the bottom tier simply does nothing.
If Musk is trying to cut 60% of the org, he's going to have a problem doing it this way. If he's trying to cut 20%, I honestly don't think it's going to misfire much of the time.
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.
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.
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
You will always have bugs. The best engineers can solve the hardest bugs
Which is a damn shame for our industry, fixing bugs should be a good career path.
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!
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.
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.
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.
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.
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 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.
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.
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.
Depends on the size and age of the company. In a startup, approximately never since the job is to build something out of nothing.
In a large enterprise with decades of codebase history to be optimized, very frequently.
I did say I wrote 30 lines of code, which was reusing other code instead of copy-pasting and changing a few things
It's not because the ratio is bad - if you wrote 300 and removed 19500 that might be fine. It's just that 30 is, in an absolute sense, too low.
The number of lines removed I don't remember and it changes nothing about the effort to read and understand the whole codebase
That's more lines of code than https://www.gnu.org/software/bash/
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.
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.
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's mostly an organisation failure.
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.
If you're also the one responsible for writing tests, you can easily churn out even more unmaintainable crap.
In my experience it's not enough to just have them do TDD, because writing a good test suite is hard.
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.
*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.
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.
I fully understand that there are circumstances where true tactical changes do make sense, but the tradeoffs should be considered up front.
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.
Sometimes people aren't being tactical; they really don't understand the system fully to know that some obvious solution will hit a snag.
I have some very basic scripts at work that I never bothered cleaning up, but maybe I can, let me look tomorrow.
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.
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".
;)
Yes, let's treat those tasks as less honourable than developers and enjoy the results
I think most people would put these in the same category as developers.
> capacity planning, monitoring and alerting, honing their troubleshooting skills
This is veering into made-up-job world. These people are getting fired. All these tasks can be done by developers.
> 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.
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.
Ah, the good old Google playbook. If you read their paper about how SRE came to be, it basically say: “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.
But if someone’s entire job is “capacity planning”, they’re getting fired.
>I think most people would put these in the same category as developers.
Yet they won't have much code to speak of, and for the bit that they do write, it probably won't be very much in the last 60 days.
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.
“IM A PEOPLE PERSON, IM GOOD WITH PEOPLE!”
Funny, since the key job description at oracle is lawyer.
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.
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.
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.
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.
https://cgit.freedesktop.org/libreoffice/core/commit/?id=3a8...
This goes against a decade of developer best practices, as enforcing code ownership promotes code silos.
I'm not saying I disagree, only that it seems contrary to recommendations.
The truth is probably somewhere in between.
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.
I'd be a little surprised if most twitter devs (and anyone else) who can leave, and aren't personally invested in Twitter, are not already doing this.
We've got a student of history
https://www.smithsonianmag.com/history/charles-proteus-stein...
There may be some three line change that was the result of eight hours of debugging and analyzing how to best fix the bug without disturbing the stuff that is working. Is that more or less productive than someone who cut & pasted a 100 line routine they found via google?