12 ms·

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

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.

Areading314 4y ago
Fixing bugs is part of the job. If you care about the product you work on, you have to fix the bugs and not whine about who originally wrote the code.
- b4je7d7wb 4y ago
  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.
  - Areading314 4y ago
    fixing bugs is more important than trivial stuff like swagger, css variables, or adding new test frameworks. Function over form
    - deleted 4y ago
      [deleted]
    - 411111111111111 4y ago
      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
      - Areading314 4y ago
        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.
        411111111111111 4y ago
        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.
        Areading314 4y ago
        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.
      - krashidov 4y ago
        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
  - paganel 4y ago
    > it's probably not the best career path. Which is a damn shame for our industry, fixing bugs should be a good career path.
    - DeathArrow 4y ago
      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!
      - qualudeheart 4y ago
        Bug fixing is fun and easy. You just need a good test suite.
  - brailsafe 4y ago
    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.
- DeathArrow 4y ago
  >If you care about the product you work on 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.
  - sbarre 4y ago
    So then you do care about the product you work on.
HWR_14 4y ago
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.
maximus-decimus 4y ago
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.
- criley2 4y ago
  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).
sheeshkebab 4y ago
> 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.
- cdavid 4y ago
  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.
  - iopq 4y ago
    What if I produced only 30 lines of code and removed 1950 lines of code?
    - xgbi 4y ago
      Maybe the metric should be "How much diff did you produce. Removing 2k LOC and being able to replace it with 30 is kind of great.
      - cdavid 4y ago
        Yes, obviously you would look at number of lines changed. Which is what git reports to you when you do git log --stat and so on.
cdavid 4y ago
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.
- pdimitar 4y ago
  I'd be very interested in such scripts, do you have links?
  - cdavid 4y ago
    If you use GH, you can use something like this: https://docs.github.com/en/enterprise-cloud@latest/organizations/collaborating-with-groups-in-organizations/viewing-insights-for-your-organization https://docs.github.com/en/enterprise-cloud@latest/organizat... I have some very basic scripts at work that I never bothered cleaning up, but maybe I can, let me look tomorrow.
    - pdimitar 4y ago
      Nice, looks like a good start. 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.
beachy 4y ago
> 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".
- thwayunion 4y ago
  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. ;)
- ithkuil 4y ago
  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
  - newone2three 4y ago
    > software getting deployed, infrastructures getting the timely upgrades.. 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.
    - thwayunion 4y ago
      >> 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.
EricDeb 4y ago
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
makeitdouble 4y ago
＞ 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.
- mlonkibjuyhv 4y ago
  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.
  - makeitdouble 4y ago
    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.
    - Valakas_ 4y ago
      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.
chris_wot 4y ago
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. https://cgit.freedesktop.org/libreoffice/core/commit/?id=3a8d16ba8ca7ef7349e893f2bf1c7e12d9a8d7ae https://cgit.freedesktop.org/libreoffice/core/commit/?id=3a8...
- Kwpolska 4y ago
  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.
pyrale 4y ago
I guess we then have to trash every profitable system when original authors leave now...
tkiolp4 4y ago
Please. If any we, developers, should be removing code. I solve problems. The fewer code I write the better.
deleted 4y ago
[deleted]
julianlam 4y ago
> Developers should be writing new code and maintaining their own code. 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.
SNosTrAnDbLe 4y ago
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
soheil 4y ago
> 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.

Areading314 4y ago

Fixing bugs is part of the job. If you care about the product you work on, you have to fix the bugs and not whine about who originally wrote the code.

b4je7d7wb 4y ago
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.
- Areading314 4y ago
  fixing bugs is more important than trivial stuff like swagger, css variables, or adding new test frameworks. Function over form
  - deleted 4y ago
    [deleted]
  - 411111111111111 4y ago
    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
    - Areading314 4y ago
      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.
      - 411111111111111 4y ago
        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.
        Areading314 4y ago
        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.
    - krashidov 4y ago
      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
- paganel 4y ago
  > it's probably not the best career path. Which is a damn shame for our industry, fixing bugs should be a good career path.
  - DeathArrow 4y ago
    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!
    - qualudeheart 4y ago
      Bug fixing is fun and easy. You just need a good test suite.
- brailsafe 4y ago
  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.
DeathArrow 4y ago
>If you care about the product you work on 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.
- sbarre 4y ago
  So then you do care about the product you work on.

HWR_14 4y ago

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.

maximus-decimus 4y ago

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.

criley2 4y ago
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).

sheeshkebab 4y ago

> 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.

cdavid 4y ago
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.
- iopq 4y ago
  What if I produced only 30 lines of code and removed 1950 lines of code?
  - xgbi 4y ago
    Maybe the metric should be "How much diff did you produce. Removing 2k LOC and being able to replace it with 30 is kind of great.
    - cdavid 4y ago
      Yes, obviously you would look at number of lines changed. Which is what git reports to you when you do git log --stat and so on.

cdavid 4y ago

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.

pdimitar 4y ago
I'd be very interested in such scripts, do you have links?
- cdavid 4y ago
  If you use GH, you can use something like this: https://docs.github.com/en/enterprise-cloud@latest/organizations/collaborating-with-groups-in-organizations/viewing-insights-for-your-organization https://docs.github.com/en/enterprise-cloud@latest/organizat... I have some very basic scripts at work that I never bothered cleaning up, but maybe I can, let me look tomorrow.
  - pdimitar 4y ago
    Nice, looks like a good start. 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.

beachy 4y ago

> 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".

thwayunion 4y ago
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. ;)
ithkuil 4y ago
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
- newone2three 4y ago
  > software getting deployed, infrastructures getting the timely upgrades.. 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.
  - thwayunion 4y ago
    >> 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.

EricDeb 4y ago

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

makeitdouble 4y ago

＞ 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.

mlonkibjuyhv 4y ago
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.
- makeitdouble 4y ago
  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.
  - Valakas_ 4y ago
    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.

chris_wot 4y ago

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. https://cgit.freedesktop.org/libreoffice/core/commit/?id=3a8d16ba8ca7ef7349e893f2bf1c7e12d9a8d7ae https://cgit.freedesktop.org/libreoffice/core/commit/?id=3a8...

Kwpolska 4y ago
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.

pyrale 4y ago

I guess we then have to trash every profitable system when original authors leave now...

tkiolp4 4y ago

Please. If any we, developers, should be removing code. I solve problems. The fewer code I write the better.

deleted 4y ago

[deleted]

julianlam 4y ago

> Developers should be writing new code and maintaining their own code. 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.

SNosTrAnDbLe 4y ago

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

soheil 4y ago

> 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.