Perhaps the reason for "nobody writes tests" in the real-world isn't primarily because of time/cost, but because virtually no real potential bugs are testable. If you're writing a JPEG encoder or database model handler, yes, you can test that all day, but those things already exist and are well-tested for you. But if you're designing retail software or a web app, there are 2^10000 things that can go wrong, so most companies ignore automated unit testing in favor of human quality control.
Absolute truths I unlearned as junior developer
61–70 of 534 posts
Re: Absolute truths I unlearned as junior developer
#62The big one for me was the realisation that the code doesn't matter . I mean sure, it does, to us. It's what we do. But really, code doesn't matter. To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for. And to the company we work for, what matters is that we solve the end user's problem, and that we do so in a…
This is true with basically everything. Game development attracts more than its fair share of truly horrid code, to the point where success seems almost inversely correlated to code quality. If you decompile Terraria (using CIL, which preserves the object design), for instance, you'll notice that its main class is over 40kLOC and that basically all of the business logic is encoded in one great big chain of if-stateme…
> all of the business logic is encoded in one great big chain of if-statements
One of the big lies of OO design is that you can manage that kind of complexity better with objects/classes, that you should factor out functionality into tiny pieces, and so on.
Unless you have written (and debugged!) an actual video game, you should spare your judgement.
Re: Absolute truths I unlearned as junior developer
#63"Loads of companies and startups have little or no tests" which should scare you, or at least it would scare me if I joined a team. You can definitely over test, but how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? There's a trade-off with testing. Early in the dev cycle, not testing can make you go super fast (supposedly, this hasn't been my p…
Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Sometimes you want that friction but in a frenetic prototyping phase its detrimental. This is especially true when business goals are changing constantly (such as early prototyping).
How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At best you could make some integration tests but that is not the same thing.
I also think there are better practices than tests to keep iteration pain low but that doesn't preclude tests so I guess that's not an argument against them. That said I prefer to focus on making composable, low side effect code than write more tests.
Personally I hate tests although I come from games where you need human QA testers to test that your game feels fun anyway so I do admit that's a unique situation.
Re: Absolute truths I unlearned as junior developer
#64The big one for me was the realisation that the code doesn't matter . I mean sure, it does, to us. It's what we do. But really, code doesn't matter. To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for. And to the company we work for, what matters is that we solve the end user's problem, and that we do so in a…
This realization is what has attracted me to the Erlang/Elixir world where fault tolerance > provable correctness.
The end user would rather have an application be frantically logging errors in the background, but be working for their usecase, than a program that is fixated with being correct and refusing to run in the presence of errors.
Obviously quality code still matters, but at least in the business realm "does it do what I expect?" is basically your success/fail state.
Re: Absolute truths I unlearned as junior developer
#65Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and…
> Understood as senior: Legacy code that I wrote myself is hard to read.
Ha, yes, I occasionally come across code I wrote years before and have a few "WTF moments"!
Re: Absolute truths I unlearned as junior developer
#66Earlier quoted context omitted.
and globals. mutable globals everywhere. (at least last time i ran away from it all after having to fix an EOL'd plugin 10 years ago). never again.
Why don't they fix it? It's long lived, it's popular, they have to maintain it. Yes, there's backwards compatibility to maintain, but surely some of it can be contained, maybe with shims, like Windows does it.
There's such a thing as taking the backwards compatibility meme too far though. You can't keep catering to those that drag their feet. Release an update and say that the legacy will no longer be supported a year from now.
Re: Absolute truths I unlearned as junior developer
#67Overall a good article, but I completely disagree with the notion that "good enough is good enough".
I've been in a lot of code reviews where developers push back because it's "good enough". You need to maintain a defined level of quality otherwise codebases go to shit very, very fast.
I was recently told in a code review that a Cassandra read before a write (to ensure there were no duplicates) was "good enough" because a duplicate "probably wouldn't happen very often". Meanwhile, the consequences of a dupe would lead to a pretty bad customer experience.
I pushed back hard and forced the developer to rewrite his entire code. Would "good enough" be okay in this situation? My bar is much higher than this developer and I stand by my decision. We have the luxury of being tasked with solving customer problems and if we only strive for "good enough" every time instead of "the best I can do within the constraints I'm given", then in my opinion your career won't be very successful. We always have to make the best tradeoffs when it comes to time and expense, but the best developers are the ones that come up with the best solution and the best code that fits in a particular constraint.
Re: Absolute truths I unlearned as junior developer
#68About two years ago, I didn't get a promotion to "senior engineer" that I thought I was going to, and I had a huge temper-tantrum to my boss about it as a result (I'm still surprised to this day that I didn't quit on the spot, to be honest). I was upset, because people that seemed to be contributing less and were less-qualified (at least from my admittedly-biased perspective at the time) were promoted to a higher lev…
Nah, f that mess. If you find yourself in a place that promotes the weak because it's a buddy system, it's not a place to work long-term. It means your boss is in 'don't rock the boat mode' and that's going to hold you back long term. Your boss should be fighting for promotions for their best workers and enabling growth in responsibility as well.
Oh, in fairness to my boss, he did make a strong effort in the next promotion cycle to get me promoted, which in fairness was only 6 months later.
The issue was the they had a limited budget for promotions, and basically limited it to one person per team. This, by itself wouldn't have bothered me too much, since the person who deserved it most on my team (someone with more experience than me, and was definitely under-leveled) did get promoted that cycle.
What upset me most was that a person on another team (with 1/3 of my experience, with no increased education, and on a team that accomplished nothing (not just my opinion, that team was disbanded a year later)) got promoted to a level higher than me. My direct boss didn't have any control on that team.
Re: Absolute truths I unlearned as junior developer
#69Earlier quoted context omitted.
> Understood as senior: Communication skills matter most. can you give examples ?
I can try. Teaching juniors can be more productive than coding. Being 10x by yourself is less good than 3x-ing a whole team. Even better, teach everyone to be as fast & good as you. Good teaching requires good communication and building trust. Understanding priorities and goals is absolutely critical to making good choices while programming. Writing good code under reasonable deadlines in an organization necessarily…
Alright, I just failed to parse what communication could mean. I see it clearly now, leadership, team work, social skills, they do indeed matter a ton.
Re: Absolute truths I unlearned as junior developer
#70Earlier quoted context omitted.
Then you have technical debt. Wordpress appeared good to end users, but we know how it is underneath and all the problem you get along[0]. It's a fine balance for sure, and forgetting that solving the problem first is what matters is a mistake indeed. [0] about that, there seem to be a 'foot in the door' effect at play. If you get users with a good enough but imperfect product, they won't mind too much if you take re…
Debt (technical and otherwise) is leverage if utilized well, and potentially crippling if abused.
I knew a shop that refused to move its customer data out of an ancient MS Access instance until one day it just started shedding records.
That's what I think of when I hear technical debt.
What are examples that make sense and don't just explode in your face?