Apart from the headline and a parenthetical reference, there isn't really any insight here about why returning to coding almost crushed him, which would have been more interesting than yet another list of things common in modern development.
I have a similar switches between management and occasional development and there are a lot of "interesting" and frustrating challenges in returning to coding after a break of several years. Hearing other people's experiences helps dealing with the frustrations. There is a lot of tooling, frameworks, build processes, etc... which weren't widespread a decade ago which make starting a side project or jumping into code only occasionally an obstacle course for those who do not do it regularly. I'm ever grateful to those who write good how to guides for these things that I can refer to when I miss a crucial step in my setup.
Yeah... smells a bit clickbaity to me! If you decide to use such a title, you should at least expand on it in the article a little bit more than the "(although it almost crushed me)" at the very end...
I have my own rule for headlines. You can almost universally swap out the word 'How' for 'That'. e.g. "That Going Back to Coding After 10 years Almost Crushed Me."
>developers now own the test writing and CI infrastructure runs and reports the tests. It has really made software more reliable
I switched from medical, with fierce QA, to more general SW dev over the last 3 years. Developers waste time writing braindead unit tests and don't stress their software like QA teams. Major bugs run undetected for weeks and cause chaos. Managers grin believing they're net-ahead.
I'm at a FANG with some of the smartest people I have ever encountered in my life, yet no one seems to agree with me that devs should not write their own tests.
There is an unwavering belief that knowing the corner cases and weak points of your own code makes you somehow better at writing the tests. We also seem to be obsessed with testing that is half-way between unit level testing and system level testing. We test APIs and features more or less in isolation.
Tests should be written by antagonistic developers who are not at all familiar with the code. They should stress the capabilities promised in the interface documentation. Hiring more people who are dedicated to testing costs a lot of money though. I don't see things changing anytime soon.
> I'm at a FANG with some of the smartest people I have ever encountered in my life, yet no one seems to agree with me that devs should not write their own tests.
> There is an unwavering belief that knowing the corner cases and weak points of your own code makes you somehow better at writing the tests. We also seem to be obsessed with testing that is half-way between unit level testing and system level testing. We test APIs and features more or less in isolation.
You're both right. Devs should write tests for their own code, but they shouldn't be the only ones writing them.
One of the problems (at least at my employer) is QA is considered a place for second-rate developers. Some of them are so bad that they rely on the devs to basically write their tests for them, by requiring extremely detailed and specific acceptance criteria. Only once have I worked with a tester that was engaged enough to really understand the requirements on their own and call out weird behavior or corner cases that weren't spelled out in advance. It was great.
> yet no one seems to agree with me that devs should not write their own tests.
I'll die on this hill. The developer that wrote the code by definition cannot write an appropriate test suite for it. It is entirely possible/probable that details missed in implementation will be missed entirely in test, as the developer missed them.
< controversial take> Manual QA promotes bad habits and is not a great thing to introduce to an org. SDETs/QA Engineers/Developers whose role is explicitly to create tests for an org are worth their salary 10x. </ controversial take >
> There is an unwavering belief that knowing the corner cases and weak points of your own code makes you somehow better at writing the tests.
This is a very common -- but inevitable -- misunderstanding.
The real reason the same person should write tests and code is if you find a person who is competent enough in both technical domain and problem domain to write the tests -- you definitely want that person to write the code as well.
See how it's not "developers should write tests"? It's "domain experts should write the tests... and domain experts should write the implementation."
Black box test - Testing a unit without any information about its internals. You provide inputs, you record outputs, and you have a spec.
By definition, the author of a unit cannot write a black box test for it. Any test they write is going to be a white box (clear box?) test, because they know how the unit works.
If you interpreted the spec incorrectly when writing the unit, you're going to interpret it incorrectly in exactly the same way when writing the test. White box testing has its place, but you need a second person if you want to do black box testing.
Writing down your program's test cases should not add much time (assuming you have test infrastructure setup like you should), since you are already having to consider these things to simply figure out what the right logic is. With a little practice, you find a good rhythm for how far to take it for yourself. In my experience, I find this actually leads to faster and more correct solutions.
2. Collect tests while in review to cover the requirements
Once you've written it though, it's always important to try and get others to look over your code and try and find flaws. Ideally, they can even write tests for you to add to the feature. This is just a standard part of any good peer review.
3. REGRESSION TEST
Finally, though I'm not sure it matters very much who writes it, regression tests are something I never see stressed enough. I feel like if you are serious about testing, every bug should be required to add at least one test to the suite before it can be closed.
That sounds like an incredibly slow feedback cycle. How would that work? Write some code, check it in, wait for someone else to write tests... and come back in hours/days/weeks to fix any issues?
Getting constantly dragged back to fix last week's bugs sounds like a chapter from Dante's Inferno. I'd rather discover them while the code is fresh in my mind.
> yet no one seems to agree with me that devs should not write their own tests.
Change Request (or whatever you call it in your flavor of agile) is the source informal description of behavior, while Specification, Code and Tests are three distinct formal descriptions of the same. If any of those three are written down by the same person, assumptions and thinking errors translate to the other largely defeating the very purpose of writing down another formal description in the first place.
Unit tests became mainstream with proliferation of weak-dynamic languages (JS, Python) and concepts like TDD largely became mainstream due to lack of formal interface specification capabilities in the languages themselves. Stricter languages (Java, C++) cover huge portions of the testing in the type system. Tests written by the developer are okay if they are used as a substitute for a formal type system. However, tests intended to catch logic errors will contain the very same logic errors found in the code and such tests will only give you false confidence.
It does not mean that tests must be written by a dedicated QA, but rather that tests should be written by a different person for them to serve the purpose they are intended to serve.
Count me in as one of those who disagree with you.
I 100% side with the grandparent comment. When you've worked with a great QA, it's night and day vs a dev writing their own tests, but a dev not writing its own tests is a nightmare.
Ideally there's a place for both and they work very closely with one another to make the software stable at all levels. It's arguable the SRE is the new QA engineer.
I'll give an example for why the original author of the code should write the test. Say you write a sort and for performance reasons you use a different algorithm beyond collection size 100. This is prone to bugs around collection size 100. Your test needs to shed light on this dark corner. A QA generalist can't know that. They write some generic test cases. Size 0, 1 and 2 since they are inherently dark corners. Then some medium size and some large collections. They'll likely miss the 100. And the bug that's there for size 99.
You need both and ideally the original author writes the test and somebody else reviews the test thoroughly. That reviewer should have an intimate understanding of the spec you are implementing.
The more formal that spec, the less need for that external reviewer since the less ambiguity there is leaving room for missunderstanding. In a perfect world, the spec is completely formalized and instead of a test that shoots in the dark, you'd write a formal machine-verified correctness proof, automatically covering all cases. Then you would not need that external reviewer and could just have the programmer do it by themselves.
> We also seem to be obsessed with testing that is half-way between unit level testing and system level testing
I think that's where most testing should live. Testing single modules means you don't test how they plug together and makes it hard to refactor responsibilities between modules, such that it often doesn't happen. Full system level testing is painful to write as you often have to mock out the world, and painful to run as it it usually slow.
The middle ground where you test a block of modules together through the top interface is a great middle ground. It does not replace the others- you need some full system level testing to check that your system integrates properly, and most modules will need some unit testing (and some will need a lot), but it's the best "bang for your buck" in terms of invested effort.
QA teams and devs write totally different tests. Devs go about it to help future refactoring, e.g. codify what the feature is supposed to do, so that if we change it in the future, we will not inadvertently break something. QAs write tests that look from the point of the user.
QA tests are arguably more valuable, but writing testable software itself can only be done if the devs too are invested in the task.
Maybe we can form DevQA teams? the way we did for DevOps and DevSecOps?
But alas, I still think having everyone though out the whole stack invested in writing tests makes the the final product better.
You're getting heavily downvoted and I'd love to know why. I've seen similar attitudes toward testing among the groups I've worked with, nobody really wants to do it.
Are folks downvoting this because they don't like testing? Is this idea that prevalent?
I think it's more appropriate to say, the quality of (enterprise?) software should not rely SOLELY on tests written by a software developer.
Is it not common knowledge already that code review is the single most valuable tool in getting rid of bugs? I remember reading it on Code Complete, maybe The Pragmatic Programmer. Can't remember.
I think there's still value in writing your own tests, at least with regard to refactoring (and sleeping better at night after deploying to production).
> Hiring more people who are dedicated to testing costs a lot of money though. I don't see things changing anytime soon.
Doesnt Google have a Software Developer in Test role? I work in a bank and every project has these people - their only job is to write automated tests (usually in Python robot framework).
Software engineers benefit from having tests that encode invariants they cannot otherwise encode in the type system, so that they have a machine assisted refactoring aid. It's just an extension of writing the code; if you think you know what you want your code to do, you just add more of that
But it's very hard for software engineers to think about what happens outside of that realm, whether because the software encounters edge cases naturally or due to "creative" ways the end users find to (ab)use the software.
Some of those cases can be explored with a fuzzer, some of them are best found with actual human QA testers.
Yeah I don't believe tests will replace testers; tests are a safety net for regressions, a safety net to allow for refactoring without changing the in- and outputs, but they are NOT a replacement for testers who look at and work with things from a user's or a business' point of view.
I mean by all means, if a tester finds an issue, write a test to replicate it before fixing it so that it can't recur.
But also, tests are code and code rots. Changing that implementation entirely voids the test. And at some point your test codebase size far exceeds that of your implementation.
That is my main beef with developer testing "braindead unit tests" I see loads of tests if `int a = b;` really happened. But everyone feels good because they are doing unit testing as "gods of agile and TDD" lined out...
Try to say that such test is useless and even harmful to long term value. You get "we all are people and make mistakes, we want to prevent that", if someone is trying to prevent wrong assignment in strongly typed language well I will call them "braindead".
And no unit tests can replace an actual person testing the software. Unit tests can catch bugs earlier but getting rid of a QA department (or even one person) manually testing features is worrisome. The developer will always be blind to their own work.
But it's not just software development, online news articles also tend to get worse with more journalists publishing without a proof-reader involved.
Hmm i think the pace of changes has made software break more, but unit tests and integration tests are an improvement. But I agree writing unit tests takes a hella lotta time, not sure if a sr eng should be doing that 1/2 the time
Absolutely my experience as well (not medical, but aviation/simulation). What's worse is when the same developers and managers pat themselves on the back for writing new unit tests to cover the discovered bugs.
I've been out of it for 30 years, and I have to dive back in. The hardware is amazingly fast compared to 1990, and as I frequently note, GIT makes a huge difference in being able to refactor, compared to a folder full of ZIP files.
The frustrating thing for me is that GUI development has apparently gone backwards a decade or so, with the rise of web frameworks and all the extra layers and connections between the user and the actual data.
It used to be that you could grab some components in VB6 or Delphi, and have your database prototype up and running in an hour, and make a stream of modifications as required, with the main delay being pkZIP and copying files prior to making any big changes, just in case. Compile cycles even then were in the 0.5-5 second range, like now.
I've wimped out and use a GUI version of GIT and GitHub, but it is amazing to start a project, and once it's running, push commits to the internet with a single click.
The main limits I see right now are,
My age - I'm 57
My skillset doesn't include the Rust, Clojure, etc...
The programming languages are less impedance matched to the human mind than they were in the past. Pascal made you type a lot of things, but that also made it far less ambiguous, and much, much easier to read and write.
I expect to wait, but not to get crushed. For me, programming is easy, except when it isn't, then its a persistence hunt for the cause of the open issue.
Every platform has regressed significantly compared to just 10 years ago. Modern UIs are slow, laggy, visually poorly designed (both in layout and in control design - they're just "flashy"), they're completely inconsistent with each other.
They seem to completely have lost 20 years to refinement in user interaction.
During the amiga times you would be yelled at for placing the "cancel" button of a dialog in the unexpected position. And I would say: rightly so. Following system guidelines to have consistency gave you great productivity as a side-effect.
Today you're lucky if you can guess that the dialog is modal at all, let alone figure out which one is the ack button and which one is a link that redirects to generic online help page.
The system design guidelines are ignored by system and app developers alike. It's a free-for-all.
I feel like living in another world when I am reading these. In what world were UI 10 years old better or good? Not that current are super great, but the past ones were neither looking better nor easier to figure out.
Can I recommend finding work in Go? It’s a good fit for “makes you type a lot of things” while being super clear what’s going on. It’s basically C with memory safety-ish and a good standard library that includes modern things.
> GUI development has apparently gone backwards a decade or so
I find this the exact opposite. Okay, maybe I could break out Delphi or Visual Basic and make a crap UI that only ran on Windows and required users to install the software.
Today, in a few minutes, I can make an app in HTML/JS that runs in a webpage and several billion people can access and use immediately on either their PC, Tablet, or phone. That it me is way better than it was 30 years ago.
And, if I want it to be an app I can use some HTML/JS wrapper and be done in a similar amount of time. I can have a new electron app up and running and on 3 platforms in under an hour. If I had more mobile experience I'm sure I could do the same there.
> And, if I want it to be an app I can use some HTML/JS wrapper and be done in a similar amount of time. I can have a new electron app up and running and on 3 platforms in under an hour. If I had more mobile experience I'm sure I could do the same there.
So now you have made a crap UI that is running on 3 platforms. It was quick and easy for you, but now every user has to suffer with a slow and bloated electron "app".
GUI development definitely has gone backwards at least a decade. Of course it can still be done right, but with so many low skill web developers everywhere, electron "apps" are what we get.
The nice thing about Windows programs was that you knew how big the display was likely to be, and more recently, the scaling has gotten much better.
The modern trend towards tiny screens that have to be scrolled in order to fit any usable amount of data in, and the various different scroll / UI paradigms means that you can technically have something that most of humanity could have access to, but most users aren't likely to be happy.
Maybe users today have zero expectations because they don't know better? I'm a dev too but my expectation as a user is higher. I never saw a modern UI framework not being a complete piece of garbage. This includes relatively "performant" stuff like QML.
I'm pretty sure regular young users would notice too, but it seems that most people just accept and adapt to crappier trends every year.
Give Go a try. It has a few unique conventions, but overall it strikes a nice balance between clarity (no surprises) and convenience. It feels like one of those languages you can fit in your head, idioms and all, kind of like C or Pascal.
The main reason why the modern Web GUI frameworks does not always feel good is because they need to support wider ranges of screen sizes, ratios, resolutions, accessibility tools, touch inputs, etc.
And web browser/css if pretty good when supporting different devices/platforms.
> My skillset doesn't include the Rust, Clojure, etc...
Don't worry about that; their usage is barely a rounding error. Skill up on (Java or C#) + (Javascript and a popular JS framework) if you want a job doing programmy things.
Surely, this guy realizes this is highly dependent on where you're working. Release managers, QA teams, and dev->test->prod issues are absolutely not gone. Arguably, dev->test->prod issues are even worse than they used to be if you're utilizing vendor-locked services that are difficult or impossible to effectively mock or simulate, and even worse than that when you're part of a multi-vendor enterprise solution where your service needs to interact with other services you don't develop and that don't actually exist yet because they're all being developed at the same time, in which case you're forced to mock an incomplete spec that may or may not end up actually getting implemented.
These new realities the author talks about are the only case if you're making sole source standalone services utilizing only externals that use stable, open APIs or standard protocols.
What sucks is when you have all these things that have to run for __your__ piece of code to work and something goes down, it's another team that has to deal with it and they're not available.
For example whatever handles oAuth in a local domain/test environment. When that goes down and the entire app/test harness doesn't work... at least there are other domains to use in our case but sometimes those are down too.
If I never have to explain again to someone that it’s THEIR JOB to investigate 500 errors from their code before someone has to come ask them about it, it’ll be too soon.
Sadly, some people interpret agile and scrum as getting rid of QA teams. Of course you can release faster if no one has to manually check the feature but it just turns the user into the QA team. And no developer can properly test their own code.
I absolutely welcome automated testing wherever possible but for any software with a user interface (including websites) it can never fully replace manual testing.
Over the last 2 decades I have switched from development to business owner/management/marketing/sales and back 3 times.
Right now, I am doing a rewrite of my online 3d engine for consumer products, after being active for 3 years as an enterprise consultant for mid and large sized organizations, mostly initiating first roadmaps and identifying how to onboard new clients, reorganizing my client's product and solution portfolios, figuring out/maturing pre-sales tracks etc...
The reason I switch from development to other tracks and back, is that after a few years I feel like I am stuck in an echo chamber, where I tend to overestimate the value of the thing I am doing, and underestimate the importance of what others do.
The biggest disadvantage is that I could have probably retired from a financial POV about a decade ago if I had stayed on the same track, while this might now take another decade, but on the other hand, for me the chase matters more than the catch.
The biggest advantage is that - due to my broad experience - my kind of profile is extremely unique, and I can find a well-paid freelance gig in about a week without to much effort if I need some cash to bridge one of my many mini-sabbaticals.
This might not be for everyone, but if you like to spend time out of your comfort zone, I would strongly advise anyone who tries to understand the bigger picture to switch every n years; it is super valuable to understand the drivers from both sides and makes the job so much more interesting.
Thanks for that. I’ve found mixing disciplines has been very helpful; especially these days, when I’m the only coder in a startup team.
But specialization is still fairly important. I am specialized in Swift (with a minor in PHP). This has been beyond invaluable, in the work I do. To be fair, I am involved in multiple platforms and tech within the Apple ecosystem (like writing stuff to work on all Apple hardware platforms), but that is still a fairly constrained environment.
I have found that it’s quite possible to write acceptable software, quickly; especially if we are willing to loop in a great deal of “mystery meat” code, but it’s another matter, entirely, to create awesome code.
I once had someone boast to me that they only hire people that can switch languages and environments in a matter of a couple of weeks.
Wide and shallow worked 20 years ago. Not so sure it is as effective, these days, as the river is a lot deeper, and runs faster.
The stakes for screwups, nowadays, are also pretty terrifying.
Going back to coding after 1 year gave me super-programming-powers! :)
I had this idea for a killer app that required a lot of deep thinking on the design to make it either a huge success or sunk it on release. I knew whatever I decided on those aspects would also be hard to implement. Every day I would just contemplate the list of pending items in my amazing project for hours, I entered in a spiral of indecision and procastrination that burned me out. Lost all interest in programming. Backed up all my code of years and cleaned my hard disk. Changed work, changed habits and hobbies. No more programming for me.
After a year I still haven't recovered my interest in programming, it must be my age, but I still believe my idea is something worth to be completed. Two weeks ago I restored my backup and was able to solve all the critical decisions, implement, test and fix bugs. That would have taken months with all the additional procastrination.
> Every day I would just contemplate the list of pending items in my amazing project for hours, I entered in a spiral of indecision and procastrination that burned me out.
This almost happened to me.
I switched to using Emacs org mode to track my personal projects. It lets me do the contemplating in a written form, and I gradually refine high-level targets into sub-tasks until one of them is small enough to implement (at which point I implement it).
It also means that if I am blocked (can't think of a good solution) on a project, I just switch o the next one and edit that org file instead.
It's worked out really well for me. My projects are still mostly unfinished, but at least now I have time-tracked against what has been done and have clear goals written down so I know where to pick up again. This means that I have actual visual feedback of progress!
After working for 20 years with weekly status, switching to daily status is a big change. It removes developer autonomy and responsibility. Instead of toughing it out and trying different ways to solve a problem, we report our status and management leads us in a different direction each morning. Instead of gaining breadth, we get emasculated. Minor problems get elevated to obsessions, inverting priorities. Over the longer time frame, all the intelligence of the leader is "harvested" and ant-like developers haven't been practicing problem-solving skill so progress ossifies, but people still feel busy because they're trying new things every day. And the new things are only from the repertoire of the leader who isn't developing either. But hey we have chip makers speeding up chips every year, so this will continue. This honestly used to be much more fun in the old days. It was less productive, of course, but also less reverent. It didn't feel like a morning mass or pledge of allegiance, more like the Superfriends.
I think this is as much an issue with your leadership roles than it is with daily stand ups in general. I worked with teams where stand ups are requested & seen as important by the team. Personally, I see the aim of stand up to inform the team of work in case it is relevant to them & ask for help if needed. How the leads of the team react determines how good a lead they are. Developers should have enough autonomy to feel they are working well & able to properly investigate, problem solve and design solutions, without affecting the overall efficiency of the team.
One of the more difficult aspects of a team lead role is balancing all the different personalities and work preferences in that team. Consider that "toughing it out" might be a desired work practice for some people but for others it's the opposite, it's leaving them struggling for longer than they need/want to be. Stand ups offer a chance to identify those situations, as not every developer will ask for help when they need it. The post stand-up follow up should then considers the individual developer's wishes (e.g. you should be able to ask to tough it out for longer, probably as long as it's not a critical blocker for other work) and that seems to be one of the places your leadership is going wrong.
Man, you must have worked at some really toxic workplaces.
I could write a paragraph reputing point by point every single one of your sentences in a healthy organization.
All I can really say is you should consider switching jobs. You'll have to take my word for it today but it's way better out there, and you can join a company and a team that will make you feel like NONE of those things (yet still have daily standups)
This sounds like a team that would be dysfunctional at doing weekly updates as much as it is now at doing daily stand-ups, except that you get bothered by it five times more often not. Don't blame Agile/daily stand-ups...
I've asked a few times my team whether they see value in our daily meetings, mentioning that it can easily disrupt flow, might have less value than ad-hoc focused meetings or chats on particular topics, and worse of all for me - might be counterproductive when we tend to wait the next day to address something and then opt to discuss it further separately.
Response is always the same: during lockdown/WFH, it is one of the few times -- sometimes the only one -- we get to talk and hear other people so they'd like to keep it.
So instead I'm trying to move away from it being a traditional scrum round-table and try to move towards chit-chat, show and tell, general updates, group quizzes, etc. All more useful probably.
I also see this as the value of stand-ups. Even in the office, it's nice to have time with the team if not everyone goes to lunch together. Forced daily interaction can be good for team productivity.
If you're repeating the same status update every day then you're either blocked or you're not offering enough detail for your status update to be useful.
In the first case you're depriving yourself of the opportunity to be helped by your team.
In the second you're depriving your teammates of the opportunity to learn from your process, insights, and potentially helping them on their own task.
Get your head out of your ass, and think about the maximum value you can provide to your team in 30seconds-2minutes in a daily status report.
> In the first case you're depriving yourself of the opportunity to be helped by your team.
I find that some people in the team want to help too much, wasting (a lot) of time on things that would've been solved in the same time by the one original person instead of by a bunch of persons while wasting multiple person's time. When someone is really stuck, then sure, but more often (in my experience) it's just the kind of stuck which is there because it just takes time to work through a particular problem and trying out solutions. I find that people often 'want to help' to show they need to be promoted / get more money because 'they are so good' and 'are such a great team player' (aka signalling instead of actually contributing to the bottom line; doing the opposite by, every day, wasting time 'helping out' instead of finishing their own tasks faster). Helping out is good, but I think daily is too often to assess (assessing from a 2minute blurb, because apparently the victim is not asking for it; they get 'help' forced upon them) if help is needed or not.
"Worked on feature ABCD yesterday, implemented part A, today will work on part B"
Repeat the next day for C, then the next day for D.
How is this useful information to anyone that it warrants a recurring meeting?
The problem is standup is useful like 5% of the time when someone is actually blocked yet for some reason we decided it needs to be every day rather than more efficient ad-hoc meetings to unblock people.
Readit News
I have a similar switches between management and occasional development and there are a lot of "interesting" and frustrating challenges in returning to coding after a break of several years. Hearing other people's experiences helps dealing with the frustrations. There is a lot of tooling, frameworks, build processes, etc... which weren't widespread a decade ago which make starting a side project or jumping into code only occasionally an obstacle course for those who do not do it regularly. I'm ever grateful to those who write good how to guides for these things that I can refer to when I miss a crucial step in my setup.
I switched from medical, with fierce QA, to more general SW dev over the last 3 years. Developers waste time writing braindead unit tests and don't stress their software like QA teams. Major bugs run undetected for weeks and cause chaos. Managers grin believing they're net-ahead.
There is an unwavering belief that knowing the corner cases and weak points of your own code makes you somehow better at writing the tests. We also seem to be obsessed with testing that is half-way between unit level testing and system level testing. We test APIs and features more or less in isolation.
Tests should be written by antagonistic developers who are not at all familiar with the code. They should stress the capabilities promised in the interface documentation. Hiring more people who are dedicated to testing costs a lot of money though. I don't see things changing anytime soon.
> There is an unwavering belief that knowing the corner cases and weak points of your own code makes you somehow better at writing the tests. We also seem to be obsessed with testing that is half-way between unit level testing and system level testing. We test APIs and features more or less in isolation.
You're both right. Devs should write tests for their own code, but they shouldn't be the only ones writing them.
One of the problems (at least at my employer) is QA is considered a place for second-rate developers. Some of them are so bad that they rely on the devs to basically write their tests for them, by requiring extremely detailed and specific acceptance criteria. Only once have I worked with a tester that was engaged enough to really understand the requirements on their own and call out weird behavior or corner cases that weren't spelled out in advance. It was great.
I'll die on this hill. The developer that wrote the code by definition cannot write an appropriate test suite for it. It is entirely possible/probable that details missed in implementation will be missed entirely in test, as the developer missed them.
< controversial take> Manual QA promotes bad habits and is not a great thing to introduce to an org. SDETs/QA Engineers/Developers whose role is explicitly to create tests for an org are worth their salary 10x. </ controversial take >
This is a very common -- but inevitable -- misunderstanding.
The real reason the same person should write tests and code is if you find a person who is competent enough in both technical domain and problem domain to write the tests -- you definitely want that person to write the code as well.
See how it's not "developers should write tests"? It's "domain experts should write the tests... and domain experts should write the implementation."
The two tasks happen to need overlapping skills.
By definition, the author of a unit cannot write a black box test for it. Any test they write is going to be a white box (clear box?) test, because they know how the unit works.
If you interpreted the spec incorrectly when writing the unit, you're going to interpret it incorrectly in exactly the same way when writing the test. White box testing has its place, but you need a second person if you want to do black box testing.
1. Write (some) tests as you develop to help you
Writing down your program's test cases should not add much time (assuming you have test infrastructure setup like you should), since you are already having to consider these things to simply figure out what the right logic is. With a little practice, you find a good rhythm for how far to take it for yourself. In my experience, I find this actually leads to faster and more correct solutions.
2. Collect tests while in review to cover the requirements
Once you've written it though, it's always important to try and get others to look over your code and try and find flaws. Ideally, they can even write tests for you to add to the feature. This is just a standard part of any good peer review.
3. REGRESSION TEST
Finally, though I'm not sure it matters very much who writes it, regression tests are something I never see stressed enough. I feel like if you are serious about testing, every bug should be required to add at least one test to the suite before it can be closed.
Just my 2-cents.
Getting constantly dragged back to fix last week's bugs sounds like a chapter from Dante's Inferno. I'd rather discover them while the code is fresh in my mind.
Without tests, how do I know when I'm done?
Change Request (or whatever you call it in your flavor of agile) is the source informal description of behavior, while Specification, Code and Tests are three distinct formal descriptions of the same. If any of those three are written down by the same person, assumptions and thinking errors translate to the other largely defeating the very purpose of writing down another formal description in the first place.
Unit tests became mainstream with proliferation of weak-dynamic languages (JS, Python) and concepts like TDD largely became mainstream due to lack of formal interface specification capabilities in the languages themselves. Stricter languages (Java, C++) cover huge portions of the testing in the type system. Tests written by the developer are okay if they are used as a substitute for a formal type system. However, tests intended to catch logic errors will contain the very same logic errors found in the code and such tests will only give you false confidence.
It does not mean that tests must be written by a dedicated QA, but rather that tests should be written by a different person for them to serve the purpose they are intended to serve.
I 100% side with the grandparent comment. When you've worked with a great QA, it's night and day vs a dev writing their own tests, but a dev not writing its own tests is a nightmare.
Ideally there's a place for both and they work very closely with one another to make the software stable at all levels. It's arguable the SRE is the new QA engineer.
You need both and ideally the original author writes the test and somebody else reviews the test thoroughly. That reviewer should have an intimate understanding of the spec you are implementing.
The more formal that spec, the less need for that external reviewer since the less ambiguity there is leaving room for missunderstanding. In a perfect world, the spec is completely formalized and instead of a test that shoots in the dark, you'd write a formal machine-verified correctness proof, automatically covering all cases. Then you would not need that external reviewer and could just have the programmer do it by themselves.
I think that's where most testing should live. Testing single modules means you don't test how they plug together and makes it hard to refactor responsibilities between modules, such that it often doesn't happen. Full system level testing is painful to write as you often have to mock out the world, and painful to run as it it usually slow.
The middle ground where you test a block of modules together through the top interface is a great middle ground. It does not replace the others- you need some full system level testing to check that your system integrates properly, and most modules will need some unit testing (and some will need a lot), but it's the best "bang for your buck" in terms of invested effort.
QA teams and devs write totally different tests. Devs go about it to help future refactoring, e.g. codify what the feature is supposed to do, so that if we change it in the future, we will not inadvertently break something. QAs write tests that look from the point of the user.
QA tests are arguably more valuable, but writing testable software itself can only be done if the devs too are invested in the task.
Maybe we can form DevQA teams? the way we did for DevOps and DevSecOps?
But alas, I still think having everyone though out the whole stack invested in writing tests makes the the final product better.
Are folks downvoting this because they don't like testing? Is this idea that prevalent?
Is it not common knowledge already that code review is the single most valuable tool in getting rid of bugs? I remember reading it on Code Complete, maybe The Pragmatic Programmer. Can't remember.
I think there's still value in writing your own tests, at least with regard to refactoring (and sleeping better at night after deploying to production).
Doesnt Google have a Software Developer in Test role? I work in a bank and every project has these people - their only job is to write automated tests (usually in Python robot framework).
Deleted Comment
Software engineers benefit from having tests that encode invariants they cannot otherwise encode in the type system, so that they have a machine assisted refactoring aid. It's just an extension of writing the code; if you think you know what you want your code to do, you just add more of that
But it's very hard for software engineers to think about what happens outside of that realm, whether because the software encounters edge cases naturally or due to "creative" ways the end users find to (ab)use the software.
Some of those cases can be explored with a fuzzer, some of them are best found with actual human QA testers.
Obligatory: https://youtu.be/baY3SaIhfl0
As always, things stop working when you just go through the motions and become cargo cults.
I mean by all means, if a tester finds an issue, write a test to replicate it before fixing it so that it can't recur.
But also, tests are code and code rots. Changing that implementation entirely voids the test. And at some point your test codebase size far exceeds that of your implementation.
Try to say that such test is useless and even harmful to long term value. You get "we all are people and make mistakes, we want to prevent that", if someone is trying to prevent wrong assignment in strongly typed language well I will call them "braindead".
But it's not just software development, online news articles also tend to get worse with more journalists publishing without a proof-reader involved.
The frustrating thing for me is that GUI development has apparently gone backwards a decade or so, with the rise of web frameworks and all the extra layers and connections between the user and the actual data.
It used to be that you could grab some components in VB6 or Delphi, and have your database prototype up and running in an hour, and make a stream of modifications as required, with the main delay being pkZIP and copying files prior to making any big changes, just in case. Compile cycles even then were in the 0.5-5 second range, like now.
I've wimped out and use a GUI version of GIT and GitHub, but it is amazing to start a project, and once it's running, push commits to the internet with a single click.
The main limits I see right now are,
I expect to wait, but not to get crushed. For me, programming is easy, except when it isn't, then its a persistence hunt for the cause of the open issue.Every platform has regressed significantly compared to just 10 years ago. Modern UIs are slow, laggy, visually poorly designed (both in layout and in control design - they're just "flashy"), they're completely inconsistent with each other.
They seem to completely have lost 20 years to refinement in user interaction.
During the amiga times you would be yelled at for placing the "cancel" button of a dialog in the unexpected position. And I would say: rightly so. Following system guidelines to have consistency gave you great productivity as a side-effect.
Today you're lucky if you can guess that the dialog is modal at all, let alone figure out which one is the ack button and which one is a link that redirects to generic online help page.
The system design guidelines are ignored by system and app developers alike. It's a free-for-all.
I find this the exact opposite. Okay, maybe I could break out Delphi or Visual Basic and make a crap UI that only ran on Windows and required users to install the software.
Today, in a few minutes, I can make an app in HTML/JS that runs in a webpage and several billion people can access and use immediately on either their PC, Tablet, or phone. That it me is way better than it was 30 years ago.
And, if I want it to be an app I can use some HTML/JS wrapper and be done in a similar amount of time. I can have a new electron app up and running and on 3 platforms in under an hour. If I had more mobile experience I'm sure I could do the same there.
So now you have made a crap UI that is running on 3 platforms. It was quick and easy for you, but now every user has to suffer with a slow and bloated electron "app".
GUI development definitely has gone backwards at least a decade. Of course it can still be done right, but with so many low skill web developers everywhere, electron "apps" are what we get.
Simply, not.
We're accustomed to great mobile/desktop UIs from big companies with dedicated people for each platform. And these UIs take months or years to polish.
An individual maybe could setup a project skeleton in 1 hour, but no more.
I do the same with Lazarus, except that my app will have a richer interface with better widgets.
The modern trend towards tiny screens that have to be scrolled in order to fit any usable amount of data in, and the various different scroll / UI paradigms means that you can technically have something that most of humanity could have access to, but most users aren't likely to be happy.
Maybe users today have zero expectations because they don't know better? I'm a dev too but my expectation as a user is higher. I never saw a modern UI framework not being a complete piece of garbage. This includes relatively "performant" stuff like QML.
I'm pretty sure regular young users would notice too, but it seems that most people just accept and adapt to crappier trends every year.
And web browser/css if pretty good when supporting different devices/platforms.
Don't worry about that; their usage is barely a rounding error. Skill up on (Java or C#) + (Javascript and a popular JS framework) if you want a job doing programmy things.
Deleted Comment
These new realities the author talks about are the only case if you're making sole source standalone services utilizing only externals that use stable, open APIs or standard protocols.
For example whatever handles oAuth in a local domain/test environment. When that goes down and the entire app/test harness doesn't work... at least there are other domains to use in our case but sometimes those are down too.
Set some alerts please.
I absolutely welcome automated testing wherever possible but for any software with a user interface (including websites) it can never fully replace manual testing.
Right now, I am doing a rewrite of my online 3d engine for consumer products, after being active for 3 years as an enterprise consultant for mid and large sized organizations, mostly initiating first roadmaps and identifying how to onboard new clients, reorganizing my client's product and solution portfolios, figuring out/maturing pre-sales tracks etc...
The reason I switch from development to other tracks and back, is that after a few years I feel like I am stuck in an echo chamber, where I tend to overestimate the value of the thing I am doing, and underestimate the importance of what others do.
The biggest disadvantage is that I could have probably retired from a financial POV about a decade ago if I had stayed on the same track, while this might now take another decade, but on the other hand, for me the chase matters more than the catch.
The biggest advantage is that - due to my broad experience - my kind of profile is extremely unique, and I can find a well-paid freelance gig in about a week without to much effort if I need some cash to bridge one of my many mini-sabbaticals.
This might not be for everyone, but if you like to spend time out of your comfort zone, I would strongly advise anyone who tries to understand the bigger picture to switch every n years; it is super valuable to understand the drivers from both sides and makes the job so much more interesting.
Edit: typo
But specialization is still fairly important. I am specialized in Swift (with a minor in PHP). This has been beyond invaluable, in the work I do. To be fair, I am involved in multiple platforms and tech within the Apple ecosystem (like writing stuff to work on all Apple hardware platforms), but that is still a fairly constrained environment.
I have found that it’s quite possible to write acceptable software, quickly; especially if we are willing to loop in a great deal of “mystery meat” code, but it’s another matter, entirely, to create awesome code.
I once had someone boast to me that they only hire people that can switch languages and environments in a matter of a couple of weeks.
Wide and shallow worked 20 years ago. Not so sure it is as effective, these days, as the river is a lot deeper, and runs faster.
The stakes for screwups, nowadays, are also pretty terrifying.
I had this idea for a killer app that required a lot of deep thinking on the design to make it either a huge success or sunk it on release. I knew whatever I decided on those aspects would also be hard to implement. Every day I would just contemplate the list of pending items in my amazing project for hours, I entered in a spiral of indecision and procastrination that burned me out. Lost all interest in programming. Backed up all my code of years and cleaned my hard disk. Changed work, changed habits and hobbies. No more programming for me.
After a year I still haven't recovered my interest in programming, it must be my age, but I still believe my idea is something worth to be completed. Two weeks ago I restored my backup and was able to solve all the critical decisions, implement, test and fix bugs. That would have taken months with all the additional procastrination.
This almost happened to me.
I switched to using Emacs org mode to track my personal projects. It lets me do the contemplating in a written form, and I gradually refine high-level targets into sub-tasks until one of them is small enough to implement (at which point I implement it).
It also means that if I am blocked (can't think of a good solution) on a project, I just switch o the next one and edit that org file instead.
It's worked out really well for me. My projects are still mostly unfinished, but at least now I have time-tracked against what has been done and have clear goals written down so I know where to pick up again. This means that I have actual visual feedback of progress!
Sick of repeating the same status update every day for no benefit.
One of the more difficult aspects of a team lead role is balancing all the different personalities and work preferences in that team. Consider that "toughing it out" might be a desired work practice for some people but for others it's the opposite, it's leaving them struggling for longer than they need/want to be. Stand ups offer a chance to identify those situations, as not every developer will ask for help when they need it. The post stand-up follow up should then considers the individual developer's wishes (e.g. you should be able to ask to tough it out for longer, probably as long as it's not a critical blocker for other work) and that seems to be one of the places your leadership is going wrong.
I could write a paragraph reputing point by point every single one of your sentences in a healthy organization.
All I can really say is you should consider switching jobs. You'll have to take my word for it today but it's way better out there, and you can join a company and a team that will make you feel like NONE of those things (yet still have daily standups)
Response is always the same: during lockdown/WFH, it is one of the few times -- sometimes the only one -- we get to talk and hear other people so they'd like to keep it.
So instead I'm trying to move away from it being a traditional scrum round-table and try to move towards chit-chat, show and tell, general updates, group quizzes, etc. All more useful probably.
In the first case you're depriving yourself of the opportunity to be helped by your team.
In the second you're depriving your teammates of the opportunity to learn from your process, insights, and potentially helping them on their own task.
Get your head out of your ass, and think about the maximum value you can provide to your team in 30seconds-2minutes in a daily status report.
I find that some people in the team want to help too much, wasting (a lot) of time on things that would've been solved in the same time by the one original person instead of by a bunch of persons while wasting multiple person's time. When someone is really stuck, then sure, but more often (in my experience) it's just the kind of stuck which is there because it just takes time to work through a particular problem and trying out solutions. I find that people often 'want to help' to show they need to be promoted / get more money because 'they are so good' and 'are such a great team player' (aka signalling instead of actually contributing to the bottom line; doing the opposite by, every day, wasting time 'helping out' instead of finishing their own tasks faster). Helping out is good, but I think daily is too often to assess (assessing from a 2minute blurb, because apparently the victim is not asking for it; they get 'help' forced upon them) if help is needed or not.
Repeat the next day for C, then the next day for D.
How is this useful information to anyone that it warrants a recurring meeting?
The problem is standup is useful like 5% of the time when someone is actually blocked yet for some reason we decided it needs to be every day rather than more efficient ad-hoc meetings to unblock people.