3 ms·
If I had to order the things that make me productive, starting with the most important: 1. It’s easy to have a fair amount of confidence in changes without eve
by yashap 5y ago
If I had to order the things that make me productive, starting with the most important:
1. It’s easy to have a fair amount of confidence in changes without even needing to run them. Strong static typing, good/clean abstractions, local reasoning - little to no mutability, code is mostly pure functions with side effects pushed to the edges. Being able to just write a bunch of code without needing to run it at all (and having it “just work” the first time, most of the time) is HUGE for productivity
2. Excellent automated test suite, with a nice pyramid (small number of E2E tests, solid number of integration tests, exhaustive unit tests). Also excellent monitoring and alerts, with automated canary releases and automated rollback. Basically make it so that it’s hard for mistakes to fully reach production. Being able to be a bit of a cowboy, safely, is huge for productivity too. I’ve worked on plenty of systems without this, and then I’m MUCH more careful, but when you really do have this, it makes everyone so much faster, especially once you learn to stop worrying and trust the guardrails (for simpler changes)
3. Test suite runs quickly locally, and is not flakey
4. Running the app locally is quick. Also ideally I can run just the one component I’m working on (like a front end, or service, or whatever), but have it fit into a full system running elsewhere
5. Full build/test/deploy process on CI is quick and reliable
This article emphasizes 3 and 4, and they’re certainly very important, but I think 1 and 2 are even more important. With them in place, often I don’t even need to do 3 and 4 for more trivial changes - just “I’m pretty certain this works,” and then the tests all pass in CI, and I’m very certain.
Compared to systems without 1 and 2, where I have to basically change a line, then run tests and/or the app because I’m not sure it’ll work, then do extensive manual testing to be sure because the automated test suite sucks. Muuuuuuch slower.
3 and 4 are great, and necessary for more complex changes, but 1 and 2 let you ship simple changes super quick, without even needing to run anything locally. That’s fastest of all, and can still be quite safe in the right environment.
- feffe 5y agoI agree with your list but really need 4 myself to be a happy camper. Often it's neglected once 2 is in place as most don't seem to find any value by it, or don't care to maintain it. I find that having the possibility to run the real thing (in some capacity) in a cozy development environment with debugger is very useful to quickly learn how parts in the system interact with each other. I have a hard time doing that with unit tests, perhaps because they are so boring.
- yashap 5y agoOh yeah, I definitely use 4 frequently too - for basically any bug ticket, or for any more complex change/new feature, I want to run the full app. Having this be fast/easy/reliable is huge. If it’s a service oriented app, and I’m modifying a single service, I especially love tools like https://www.telepresence.io/ https://www.telepresence.io/ - run my service locally, with an “auto recompile/reload on save” setup (and sometimes a debugger), while all the other services are running in the cloud, but communicate with my local service. However, a lot of changes are just small, trivial tweaks, and if 1 and 2 are strong, I don’t even have to bother with 3 or 4.
- commandlinefan 5y ago> Being able to just write a bunch of code without needing to run it at all I work with a frightening number of programmers who assume that they can do this... so much so that they never bother testing to see if they were correct in the first place.
- yashap 5y agoFWIW, I always write tests for my changes, as long as they have any impact on behaviour (i.e. not writing tests for adding a little logging or metrics, but am for any new or modified business logic). Every single dev having a strong commitment to automated testing is a requirement for an environment where you can sometimes get away without manual testing. For any changes where it's not obvious that it'll work in practice, despite the tests, I also run the full app locally, and test manually. Or for any UI changes, obviously. For backend changes, for some codebases, running the full app locally is required for ANY change, period - hard to reason about code, little-to-no type safety, weak overall test coverage, etc. But if you have a simple backend change in an easy to reason about code base, that has great guardrails (great automated test coverage, great monitoring/alerts, canary deploys with auto-rollback), there really is not much reason to actually run the full app for a simple change, which is a nice productivity boost. Just make the tweak, write/modify tests if necessary, and if everything passes on CI, you're good to go. For the 8 years before my current job, I was working in environments that weren't safe enough to do this ever, and was horrified when devs would merge without actually manually testing their changes. But my current company/environment has a codebase with strong typing and nice abstractions/local reasoning, great automated test coverage, and great monitoring/alerts and canary deploys with auto-rollback. Took me a bit, but I've embraced the "no need to run the app for simple changes" approach, and it works great in this environment - highly productive and still safe enough.
- commandlinefan 5y ago> I always write tests for my changes I wasn't saying you were one of those people - just saying I've worked with a lot of them.