7 ms·

For developers under pressure, it’s better for bugs to be found in production

71 points by KingOfCoders 3y ago

Justsignedup 3y ago
I found that a suite of useful tests speed up my development by a lot. Tests that test services that do interesting thing in my code. I find that I can get 90% of my work done without ever firing up a web browser. It's cool to know that by the time you hit up the ui the code already works perfectly and I spent less time coding than otherwise. So idk what this article is pointing out. Tests for test sake is probably that, but a big chunk of unit testing is definitely not bad for developers.
- orwin 3y ago
  I don't think you're getting the point (you might be in a small, or in a great team). Tests are great for the codebase, for stability, for onboarding. But for devs who have management/exec pressure, and especially if the team is 'agile', they will slow your sprint, discover edge cases or bugs you never put in your cards and ultimately 'slow down' initial development, and if your company is especially bad, you'll get performance reviews. If you let the edge case/bug happen in prod, it'll take more time to correct it than if you caught it prior to that, you might have to modify an loop or a data structure and introduce more bugs, but at least the software was delivered in time, and you'll get paid for that time spent correcting those bug if you're a contractor.
nine_zeros 3y ago
> When found during development, developers need to write a fix; the time spent counts against “development time.” They are blamed for missed deadlines (Newspeak “Sprint and Goals”). They are asked why everything takes so long. Ironically, they are blamed for creating high-quality code. Sad, I know. Hahaha, I have been penalized for going steady enough times that I reached a point where I have no incentive to make services any better. I found it better to sweep issues under the rug and switch teams before it blows up. It pains me but I am not going to care about it if I am going to be penalized for it.
gdsdfe 3y ago
I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks
- ahofmann 3y ago
  Doing both is good. Integration tests tells you that something is broken. Unit tests tells you where it broke.
  - The_Colonel 3y ago
    Unit tests (which have to mock dependencies) have a very bad signal-to-noise ratio. Most of their breakages are caused by forgetting to reflect the latest implementation details in the test code (like mocking new dependencies). I write unit tests only if the logic is completely encapsulated by the "unit". The less you need to mock, the higher value the tests bring. That's one of the reasons I prefer to work on monoliths, it's much easier to test almost-end-to-end.
- prerok 3y ago
  I disagree. Unit tests, when done right, are heaps of ROI in my experience. Most of the integration tests are for happy paths, i.e. ones where you can catch the obvious regressions. Testing corner cases is much more troublesome, because you have to set up a whole lot of specifics in multiple services. These are much easier to simulate with mocks. Mind you, I hate unit tests for specific functions: I much prefer them as component tests, where you start with the inputs to the module and check the outputs and calls outside of the module. These ease refactoring where you actually change the underlying code and without changing the unit tests, you know that you also handled all those pesky corner cases.
- adrianmonk 3y ago
  They are valuable in different ways. Integration tests are better at accurately reflecting the real software. There is less of a leap of faith between "this test passes" and "the software actually works". Unit tests are better at telling you exactly what failed. There is less of a research project between "this test fails" and "this code right here needs to be fixed". I don't really love anxiety-inducing leaps of faith or time-consuming research projects, but I don't know of one form of testing that avoids both.
r0s 3y ago
Maybe not perfectly framed, but the point that engineers don't have time to write tests is salient. Minor disagreement with this point though: > Tests can only tell developers they made a mistake. There is no gain at that moment. The value is locating the problem code faster, and that generally can't be done efficiently in production. Outside a testing environment, you rely on logs alone to debug, or if you're more proactive you might grab session data but that means potentially sensitive user data is being cached and passed around to the support/triage team. At a security minded organization this should be impossible or at least difficult. I agree it's not worth chasing Test Driven Development until you're actually testing during development. This is a real problem, and it falls squarely on management. Testing needs time and resources, it needs priority and planning. That's the reason I started speaking at conferences, started an online testing training course specifically for software managers, and am currently writing a book on the subject.
- thakoppno 3y ago
  > potentially sensitive user data is being cached and passed around to the support/triage team An excellent point for most cases that ultimately cannot be satisfied for others. For instance, this most recent HTTP/2 Rapid Reset vulnerability, could it be solved without shared PCAPs?
- dickersnoodle 3y ago
  >> Tests can only tell developers they made a mistake. There is no gain at that moment. This is the dumbest thing I have seen on HN in a long, long time. Full test coverage supported by good mocks is one of the quickest and most efficient ways to find regressions that I know. Don't discount the value in helping developers see when they've made mistakes, especially when you're rotating junior and mid-level developers on and off your team.
- l72 3y ago
  When we have business logic changes or a bug fix, I require our developers to write test cases for the new behavior and commit that. I want to see those test fail in the CI systems. THEN they can implement the changes until the tests pass. When reviewing, the first thing I do is look at the tests. That is how I make sure developers understood the new requirements. Only after verifying that, so I then do a code review to critique implementation.
jackblemming 3y ago
Developer's dont write tests if writing tests is hard. Simple as that. If writing tests is hard because you never invested in setting up a good test infrastructure with helpful utilities, you fucked up. If writing tests is hard because your architecture is a cluster fuck of mixed responsibilities, you fucked up.
- imbnwa 3y ago
  Man have I been on either side of those
- kapitanjakc 3y ago
  Can I still not write tests because I don't know how or because I simply don't want to and put the "fucked up" pin on someone else ?
  - rozenmd 3y ago
    > I don't know how See the first point
    - kapitanjakc 3y ago
      Hell yeah.
- ajmurmann 3y ago
  This is were good tech leadership matters. Leadership must push back on product to make room too build out test infrastructure. Otherwise you'll see individual engineers who do the right thing get punished for it because get aren't delivering tickets.
  - dickersnoodle 3y ago
    Word. I work for a reasonably large online retailer that fancies itself a "tech company" and you'd be amazed at the pushback I kept getting for insisting on a proper test infrastructure for their mobile apps - dependency injection for mock API endpoints with captured data, fuzzing to capture UI weaknesses and the like. But no, they need to go fast because... well, because their product/market fit isn't that stable and they're using "data driven" decision making to justify chasing one rabbit after another to try and juice the stock price.
nuttingd 3y ago
> (Newspeak “Sprint and Goals”) Sprint "commitments" in my world. A single word with major psychological impacts.
violetthrift 3y ago
> So if tests are bad for developers, they won’t write tests, duh. Paradox solved. There need to be tests written, no exceptions, for some time to gain the benefits and make tests good for developers. Make tests work for them and they will write more. This doesn't actually fix the incentive problem, though. If the reason developers don't like writing tests is because finding bugs puts them under additional pressure and isn't rewarded, requiring this so doesn't actually help them. Unless, of course, management comes to understand and accept that more time will be spent fixing bugs/improving code quality as a result.
iamnafets 3y ago
Sounds like the problem is engineers aren't accountable for quality. Rather than prescribing a solution, these leaders should make sure incentives are correct in their organization.
- add-sub-mul-div 3y ago
  As an engineer I made myself responsible for quality for my whole career back when I had the freedom to guide my own work. Under agile/scrum I'm too unengaged to care what works in production and don't accept the idea of responsibility without authority and autonomy.
  - iamnafets 3y ago
    Agreed. Scrum, in most cases, robs engineers of the agency they need to deliver maximum value. My teams did better work without it under the condition that the talent was motivated, technically proficient, and had the right incentives.
- nine_zeros 3y ago
  > Sounds like the problem is engineers aren't accountable for quality. Rather than prescribing a solution, these leaders should make sure incentives are correct in their organization. A low effort management practice is to make engineers move fast at the expense of quality. An even lower effort practice is to then turn around and hold engineers accountable for the choices made by management in the first place.
  - iamnafets 3y ago
    The obvious needle thread here is to not "make" engineers do anything, but hold them accountable to the results the business needs to see. The best teams are composed of empowered, accountable engineers who have the flexibility to do what they're paid to do.
    - nine_zeros 3y ago
The_Colonel 3y ago
The central hypothesis is that developers are not writing tests since they prefer bugs popping up on production instead of during development, and it seems quite absurd. I've been in many dev teams in many companies, but haven't seen incentives to be that much messed up. One reason this doesn't make much sense is that this requires hoping that the bugs pass QA. If QA finds those bugs, sends them back to dev, then they still have to fix that + very significant time overhead of this round trip which doesn't make it "worth it".
- CSMastermind 3y ago
  I mean I've seen it happen with unrealistic stakeholders. Business forces the team to make a false commitment to a specific ship date with a specific set of features. It's obvious that the team can't hit that mark but telling the stakeholders that will just result in them refusing to budge and telling you that you need to come up with a plan to make it happen. Eventually it's easier to just agree with them and do your best than waste even more time arguing with them. Eventually you fail to ship or you ship a buggy mess. The software engineers know the code quality is shit but they don't have time to think or set anything up.
  - pylua 3y ago
    That is called fraud.
    - deleted 3y ago
      [deleted]
  - thowaway91234 3y ago
    It’s either more time or less features. Less testing is non-negotiable.
    - harimau777 3y ago
      Developers generally don't have the power to make that decision.
kapitanjakc 3y ago
The real reason I don't write the tests:- Client/ Manager :- When is this going to be ready? Me :- Estimated time for development is n1 days and around n2 days for testing, and depending on the bugs n3 days to fix them. Client/manager :- No no, we don't have time, do it in n1-1 days. And when you ship it with bugs, they have a shocked Pikachu face.
- mbrumlow 3y ago
  You have to start with test first -- just make them "the task". Don't give estimates separated by test and features. New feature at hand? First thing you code is the scaffolding to call or trigger new feature (this may be trivial on some projects, or impossible on others). So long as you start out that way when asked, how long? The tail end always contains the feature, and they can't say cut it. I worked at a place once where I was setting up a minimal CI/CD pipeline for the project -- I took the first few weeks to do this. In a meeting I was called out by another engineer that had longer tenure at the company. "Are you working on 'devops' stuff because you don't know how to do the primary objective". I responded with a very long triad of why all this other stuff IS the primary objective, and was never questioned again (by that same engineer anyways). All this to say, part of being an engineer is also to educate fellow engineers on ways of doing things better than status quo. It can be hard, and you can put your self at risk. But it's a choice you have to make for your self, the engineer who cuts corners to make mostly arbitrary deadlines, or the one who build robust software. You don't have to go in 100%, but at least have a leaning to one side or the other and make the better choice when it really matters.
  - lamontcg 3y ago
    Yeah +1 on not even talking to anyone in management about tests. I've never talked about solving problems like that, always just talked about the time to fix the bug / implement the feature, and test were implicitly part of that. I've also never had a manager start micromanaging me over how many tests I was writing. That's always been my own judgment call to make.
  - kderbyma 3y ago
    that assumes you have the leeway to take longer. a lot of issues arise when there is an unforeseen deadline and you get just enough time to get out the code with some bugs and then can add tests and refactor afterwards. usually this happens when a critical component suddenly gets sunset and you need to work in a work around temporarily until you can do it right
nightowl_games 3y ago
"bug fix sprint" sounds like a horrible inefficiency. Is that the goal? Is the goal to constantly weasel more time out of your manager? That's not my goal. I like delivering high quality stuff to users. I like 'moving the needle'. I like coming up with a plan to produce business value, and doing it. I like getting stuff done. This article perpetuates the 'developer vs manager' concept which is a ridiculous mindset rooted in primitive human flaws. Fix your relationships with your colleagues and work together to make quality stuff. No deception. Only cooperation.
- berkes 3y ago
  I think you are arguing exactly what the article argues. That this dev vs manager, and all that comes from it, is bad.
- nine_zeros 3y ago
  > Fix your relationships with your colleagues and work together to make quality stuff. No deception. Only cooperation. Can you tell this to my manager? Especially the "no deception" part?
justinator 3y ago
I see the author is from the, "move fast and break stuff" school of engineering. How old school.
aranchelk 3y ago
> Tests are bad for developers. That is why. They can only detect bugs. Tests can only tell developers they made a mistake. There is no gain at that moment. When test-driven development is applicable, it’s so damn nice. If for no other reason, just because it requires so many fewer keystrokes and clicks, just have a process watching for changes and rerunning the test suite. Less chance of developing RSI, it’s good for developers. I added the caveat “when applicable” because for straight-up UI behaviors it’s not, but the longer I write code, the more I see ways to separate out pure logic from UI and other external effects and I’ve never regretted doing it for reasons including: general reasoning, readability, TDD, future changes, and bug fixes.
deleted 3y ago
[deleted]
miki123211 3y ago
> Code Monkey think maybe manager want to write god damned login page himself For those that don't know, this is a reference to: https://www.youtube.com/watch?v=AEBld6I_AKs https://www.youtube.com/watch?v=AEBld6I_AKs
GreenAlien 3y ago
I worked on a project where we handled the results of an API call. For testing we mocked the various API call results. When we went live, we discovered they had changed the results of the API call. All the testing was worthless. Still, I hate having bugs in my code and strive to make sure they don't happen. Still I have had managers release my code when I tell them there are active bugs being worked on.
josephmosby 3y ago
We have an alternative path that works for us: get a terrible, ugly, but functional version of the feature up as quickly as possible. Preferably, the uglier the better. Skip the tests for now. Put it behind a feature flag or some other way to "get it into production" without any real users able to see it. This lets you try the feature out end-to-end. Click buttons that call APIs and see if the right actions occur. Fix all the stuff that breaks when you first try this out. Then show it to a friendly. Product manager maybe, engineering manager, another developer... whatever. Someone who understands you're just looking for someone to try out this feature with you. It works now? Great. Put unit and integration tests around it. Make sure that this happy thing you have running won't accidentally break. Now make it pretty. Give it the design product actually asked for. They'll have feedback, which you can now incorporate safely because you have tests.

71 points by KingOfCoders 3y ago

I found that a suite of useful tests speed up my development by a lot. Tests that test services that do interesting thing in my code. I find that I can get 90% of my work done without ever firing up a web browser. It's cool to know that by the time you hit up the ui the code already works perfectly and I spent less time coding than otherwise. So idk what this article is pointing out. Tests for test sake is probably that, but a big chunk of unit testing is definitely not bad for developers.

orwin 3y ago
I don't think you're getting the point (you might be in a small, or in a great team). Tests are great for the codebase, for stability, for onboarding. But for devs who have management/exec pressure, and especially if the team is 'agile', they will slow your sprint, discover edge cases or bugs you never put in your cards and ultimately 'slow down' initial development, and if your company is especially bad, you'll get performance reviews. If you let the edge case/bug happen in prod, it'll take more time to correct it than if you caught it prior to that, you might have to modify an loop or a data structure and introduce more bugs, but at least the software was delivered in time, and you'll get paid for that time spent correcting those bug if you're a contractor.

nine_zeros 3y ago

> When found during development, developers need to write a fix; the time spent counts against “development time.” They are blamed for missed deadlines (Newspeak “Sprint and Goals”). They are asked why everything takes so long. Ironically, they are blamed for creating high-quality code. Sad, I know. Hahaha, I have been penalized for going steady enough times that I reached a point where I have no incentive to make services any better. I found it better to sweep issues under the rug and switch teams before it blows up. It pains me but I am not going to care about it if I am going to be penalized for it.

gdsdfe 3y ago

I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks

ahofmann 3y ago
Doing both is good. Integration tests tells you that something is broken. Unit tests tells you where it broke.
- The_Colonel 3y ago
  Unit tests (which have to mock dependencies) have a very bad signal-to-noise ratio. Most of their breakages are caused by forgetting to reflect the latest implementation details in the test code (like mocking new dependencies). I write unit tests only if the logic is completely encapsulated by the "unit". The less you need to mock, the higher value the tests bring. That's one of the reasons I prefer to work on monoliths, it's much easier to test almost-end-to-end.
prerok 3y ago
I disagree. Unit tests, when done right, are heaps of ROI in my experience. Most of the integration tests are for happy paths, i.e. ones where you can catch the obvious regressions. Testing corner cases is much more troublesome, because you have to set up a whole lot of specifics in multiple services. These are much easier to simulate with mocks. Mind you, I hate unit tests for specific functions: I much prefer them as component tests, where you start with the inputs to the module and check the outputs and calls outside of the module. These ease refactoring where you actually change the underlying code and without changing the unit tests, you know that you also handled all those pesky corner cases.
adrianmonk 3y ago
They are valuable in different ways. Integration tests are better at accurately reflecting the real software. There is less of a leap of faith between "this test passes" and "the software actually works". Unit tests are better at telling you exactly what failed. There is less of a research project between "this test fails" and "this code right here needs to be fixed". I don't really love anxiety-inducing leaps of faith or time-consuming research projects, but I don't know of one form of testing that avoids both.

r0s 3y ago

Maybe not perfectly framed, but the point that engineers don't have time to write tests is salient. Minor disagreement with this point though: > Tests can only tell developers they made a mistake. There is no gain at that moment. The value is locating the problem code faster, and that generally can't be done efficiently in production. Outside a testing environment, you rely on logs alone to debug, or if you're more proactive you might grab session data but that means potentially sensitive user data is being cached and passed around to the support/triage team. At a security minded organization this should be impossible or at least difficult. I agree it's not worth chasing Test Driven Development until you're actually testing during development. This is a real problem, and it falls squarely on management. Testing needs time and resources, it needs priority and planning. That's the reason I started speaking at conferences, started an online testing training course specifically for software managers, and am currently writing a book on the subject.

thakoppno 3y ago
> potentially sensitive user data is being cached and passed around to the support/triage team An excellent point for most cases that ultimately cannot be satisfied for others. For instance, this most recent HTTP/2 Rapid Reset vulnerability, could it be solved without shared PCAPs?
dickersnoodle 3y ago
>> Tests can only tell developers they made a mistake. There is no gain at that moment. This is the dumbest thing I have seen on HN in a long, long time. Full test coverage supported by good mocks is one of the quickest and most efficient ways to find regressions that I know. Don't discount the value in helping developers see when they've made mistakes, especially when you're rotating junior and mid-level developers on and off your team.
l72 3y ago
When we have business logic changes or a bug fix, I require our developers to write test cases for the new behavior and commit that. I want to see those test fail in the CI systems. THEN they can implement the changes until the tests pass. When reviewing, the first thing I do is look at the tests. That is how I make sure developers understood the new requirements. Only after verifying that, so I then do a code review to critique implementation.

jackblemming 3y ago

Developer's dont write tests if writing tests is hard. Simple as that. If writing tests is hard because you never invested in setting up a good test infrastructure with helpful utilities, you fucked up. If writing tests is hard because your architecture is a cluster fuck of mixed responsibilities, you fucked up.

imbnwa 3y ago
Man have I been on either side of those
kapitanjakc 3y ago
Can I still not write tests because I don't know how or because I simply don't want to and put the "fucked up" pin on someone else ?
- rozenmd 3y ago
  > I don't know how See the first point
  - kapitanjakc 3y ago
    Hell yeah.
ajmurmann 3y ago
This is were good tech leadership matters. Leadership must push back on product to make room too build out test infrastructure. Otherwise you'll see individual engineers who do the right thing get punished for it because get aren't delivering tickets.
- dickersnoodle 3y ago
  Word. I work for a reasonably large online retailer that fancies itself a "tech company" and you'd be amazed at the pushback I kept getting for insisting on a proper test infrastructure for their mobile apps - dependency injection for mock API endpoints with captured data, fuzzing to capture UI weaknesses and the like. But no, they need to go fast because... well, because their product/market fit isn't that stable and they're using "data driven" decision making to justify chasing one rabbit after another to try and juice the stock price.

nuttingd 3y ago

> (Newspeak “Sprint and Goals”) Sprint "commitments" in my world. A single word with major psychological impacts.

violetthrift 3y ago

> So if tests are bad for developers, they won’t write tests, duh. Paradox solved. There need to be tests written, no exceptions, for some time to gain the benefits and make tests good for developers. Make tests work for them and they will write more. This doesn't actually fix the incentive problem, though. If the reason developers don't like writing tests is because finding bugs puts them under additional pressure and isn't rewarded, requiring this so doesn't actually help them. Unless, of course, management comes to understand and accept that more time will be spent fixing bugs/improving code quality as a result.

iamnafets 3y ago

Sounds like the problem is engineers aren't accountable for quality. Rather than prescribing a solution, these leaders should make sure incentives are correct in their organization.

add-sub-mul-div 3y ago
As an engineer I made myself responsible for quality for my whole career back when I had the freedom to guide my own work. Under agile/scrum I'm too unengaged to care what works in production and don't accept the idea of responsibility without authority and autonomy.
- iamnafets 3y ago
  Agreed. Scrum, in most cases, robs engineers of the agency they need to deliver maximum value. My teams did better work without it under the condition that the talent was motivated, technically proficient, and had the right incentives.
nine_zeros 3y ago
> Sounds like the problem is engineers aren't accountable for quality. Rather than prescribing a solution, these leaders should make sure incentives are correct in their organization. A low effort management practice is to make engineers move fast at the expense of quality. An even lower effort practice is to then turn around and hold engineers accountable for the choices made by management in the first place.
- iamnafets 3y ago
  The obvious needle thread here is to not "make" engineers do anything, but hold them accountable to the results the business needs to see. The best teams are composed of empowered, accountable engineers who have the flexibility to do what they're paid to do.
  - nine_zeros 3y ago

The_Colonel 3y ago

The central hypothesis is that developers are not writing tests since they prefer bugs popping up on production instead of during development, and it seems quite absurd. I've been in many dev teams in many companies, but haven't seen incentives to be that much messed up. One reason this doesn't make much sense is that this requires hoping that the bugs pass QA. If QA finds those bugs, sends them back to dev, then they still have to fix that + very significant time overhead of this round trip which doesn't make it "worth it".

CSMastermind 3y ago
I mean I've seen it happen with unrealistic stakeholders. Business forces the team to make a false commitment to a specific ship date with a specific set of features. It's obvious that the team can't hit that mark but telling the stakeholders that will just result in them refusing to budge and telling you that you need to come up with a plan to make it happen. Eventually it's easier to just agree with them and do your best than waste even more time arguing with them. Eventually you fail to ship or you ship a buggy mess. The software engineers know the code quality is shit but they don't have time to think or set anything up.
- pylua 3y ago
  That is called fraud.
  - deleted 3y ago
    [deleted]
- thowaway91234 3y ago
  It’s either more time or less features. Less testing is non-negotiable.
  - harimau777 3y ago
    Developers generally don't have the power to make that decision.

kapitanjakc 3y ago

The real reason I don't write the tests:- Client/ Manager :- When is this going to be ready? Me :- Estimated time for development is n1 days and around n2 days for testing, and depending on the bugs n3 days to fix them. Client/manager :- No no, we don't have time, do it in n1-1 days. And when you ship it with bugs, they have a shocked Pikachu face.

mbrumlow 3y ago
You have to start with test first -- just make them "the task". Don't give estimates separated by test and features. New feature at hand? First thing you code is the scaffolding to call or trigger new feature (this may be trivial on some projects, or impossible on others). So long as you start out that way when asked, how long? The tail end always contains the feature, and they can't say cut it. I worked at a place once where I was setting up a minimal CI/CD pipeline for the project -- I took the first few weeks to do this. In a meeting I was called out by another engineer that had longer tenure at the company. "Are you working on 'devops' stuff because you don't know how to do the primary objective". I responded with a very long triad of why all this other stuff IS the primary objective, and was never questioned again (by that same engineer anyways). All this to say, part of being an engineer is also to educate fellow engineers on ways of doing things better than status quo. It can be hard, and you can put your self at risk. But it's a choice you have to make for your self, the engineer who cuts corners to make mostly arbitrary deadlines, or the one who build robust software. You don't have to go in 100%, but at least have a leaning to one side or the other and make the better choice when it really matters.
- lamontcg 3y ago
  Yeah +1 on not even talking to anyone in management about tests. I've never talked about solving problems like that, always just talked about the time to fix the bug / implement the feature, and test were implicitly part of that. I've also never had a manager start micromanaging me over how many tests I was writing. That's always been my own judgment call to make.
- kderbyma 3y ago
  that assumes you have the leeway to take longer. a lot of issues arise when there is an unforeseen deadline and you get just enough time to get out the code with some bugs and then can add tests and refactor afterwards. usually this happens when a critical component suddenly gets sunset and you need to work in a work around temporarily until you can do it right

nightowl_games 3y ago

"bug fix sprint" sounds like a horrible inefficiency. Is that the goal? Is the goal to constantly weasel more time out of your manager? That's not my goal. I like delivering high quality stuff to users. I like 'moving the needle'. I like coming up with a plan to produce business value, and doing it. I like getting stuff done. This article perpetuates the 'developer vs manager' concept which is a ridiculous mindset rooted in primitive human flaws. Fix your relationships with your colleagues and work together to make quality stuff. No deception. Only cooperation.

berkes 3y ago
I think you are arguing exactly what the article argues. That this dev vs manager, and all that comes from it, is bad.
nine_zeros 3y ago
> Fix your relationships with your colleagues and work together to make quality stuff. No deception. Only cooperation. Can you tell this to my manager? Especially the "no deception" part?

justinator 3y ago

I see the author is from the, "move fast and break stuff" school of engineering. How old school.

aranchelk 3y ago

> Tests are bad for developers. That is why. They can only detect bugs. Tests can only tell developers they made a mistake. There is no gain at that moment. When test-driven development is applicable, it’s so damn nice. If for no other reason, just because it requires so many fewer keystrokes and clicks, just have a process watching for changes and rerunning the test suite. Less chance of developing RSI, it’s good for developers. I added the caveat “when applicable” because for straight-up UI behaviors it’s not, but the longer I write code, the more I see ways to separate out pure logic from UI and other external effects and I’ve never regretted doing it for reasons including: general reasoning, readability, TDD, future changes, and bug fixes.

deleted 3y ago

[deleted]

miki123211 3y ago

> Code Monkey think maybe manager want to write god damned login page himself For those that don't know, this is a reference to: https://www.youtube.com/watch?v=AEBld6I_AKs https://www.youtube.com/watch?v=AEBld6I_AKs

GreenAlien 3y ago

I worked on a project where we handled the results of an API call. For testing we mocked the various API call results. When we went live, we discovered they had changed the results of the API call. All the testing was worthless. Still, I hate having bugs in my code and strive to make sure they don't happen. Still I have had managers release my code when I tell them there are active bugs being worked on.

josephmosby 3y ago

We have an alternative path that works for us: get a terrible, ugly, but functional version of the feature up as quickly as possible. Preferably, the uglier the better. Skip the tests for now. Put it behind a feature flag or some other way to "get it into production" without any real users able to see it. This lets you try the feature out end-to-end. Click buttons that call APIs and see if the right actions occur. Fix all the stuff that breaks when you first try this out. Then show it to a friendly. Product manager maybe, engineering manager, another developer... whatever. Someone who understands you're just looking for someone to try out this feature with you. It works now? Great. Put unit and integration tests around it. Make sure that this happy thing you have running won't accidentally break. Now make it pretty. Give it the design product actually asked for. They'll have feedback, which you can now incorporate safely because you have tests.