3 ms·

Yep. I work for Big Tech, and our CI was lacking for a very long time. Integration testing isn't prioritized at all. Ironic to write code in an overly pedantic

Yep. I work for Big Tech, and our CI was lacking for a very long time. Integration testing isn't prioritized at all. Ironic to write code in an overly pedantic language with type safety, spend 3X that time on unit tests with near-100% coverage and what-if analysis, and still have the thing just not work in the end. For my own projects, I went TDD with integration tests first, and it paid off in both the short and long term. Soon after activated CI (thanks Heroku Pipelines). Actual functionality was more complex than what my day job project does, and my way of doing things wouldn't have been allowed there, yet it was more stable in the end. Amazing what you can do when nobody is telling you what to do.

culi 4y ago
I think the impressive thing would've been you being able to achieve that while coordinating with multiple other people. Anybody can write "perfect" code with enough reading/practice. I think being able to fit your code within the context of a codebase is another skillset entirely and presents entirely different challenges regardless of management influence
- hot_gril 4y ago
  One time I used that approach was in a small startup. I was working with frontend contractors, so I collaborated with them on FRs, API design, and bug reports, but it was mostly separate coding-wise. TDD and docs mattered a lot due to the 12hr time diff and language barrier. The only other backend dev came at the end, and I handed the whole thing off to him. Aside from that, business people. I only write code that's just good enough. My goal was to quickly handle the business requirements that were a bit of a moving target and keep prod stable, and I did. If we had more people, a few parts of it would've been handed off as services that work similarly to my piece. And I know they would've been fine because my system was nothing special or pretentious, just your typical NodeJS/Postgres backends plus a few other pieces. The frontend devs understood it well enough to tweak new features occasionally if I was asleep. Big Tech(tm) team would've been fine with this too. We have roughly the same-size system and resources I did, and similar relations with internal customers, except 5 backend SWEs instead of 1, and except we're forced to do things the hard way. FRs take forever, and the system is flaky.

culi 4y ago

I think the impressive thing would've been you being able to achieve that while coordinating with multiple other people. Anybody can write "perfect" code with enough reading/practice. I think being able to fit your code within the context of a codebase is another skillset entirely and presents entirely different challenges regardless of management influence

hot_gril 4y ago
One time I used that approach was in a small startup. I was working with frontend contractors, so I collaborated with them on FRs, API design, and bug reports, but it was mostly separate coding-wise. TDD and docs mattered a lot due to the 12hr time diff and language barrier. The only other backend dev came at the end, and I handed the whole thing off to him. Aside from that, business people. I only write code that's just good enough. My goal was to quickly handle the business requirements that were a bit of a moving target and keep prod stable, and I did. If we had more people, a few parts of it would've been handed off as services that work similarly to my piece. And I know they would've been fine because my system was nothing special or pretentious, just your typical NodeJS/Postgres backends plus a few other pieces. The frontend devs understood it well enough to tweak new features occasionally if I was asleep. Big Tech(tm) team would've been fine with this too. We have roughly the same-size system and resources I did, and similar relations with internal customers, except 5 backend SWEs instead of 1, and except we're forced to do things the hard way. FRs take forever, and the system is flaky.