HackerTrans
TopNewTrendsCommentsPastAskShowJobs

ndmeredian

no profile record

comments

ndmeredian
·hace 5 años·discuss
As a developer I've been on both sides with my current 10-years experience. Not largest, but enough to make certain conclusions. And yeah, I do like being software developer, I like both coding, "solving challenging problems" and product-related work.

I would say I don't really support "You still work8h by thinking while you sleep" - while it's generally true, I think it somewhat shifts the point. I know that other day you event can't sleep since you mind is still boiling with processing. But there's other point.

In my younger ages I was completely consumed by work. Startups, 12-hours coding runs for weeks, constant learning, all that stuff. That was physically draining, but I had enough resource to accommodate that & still was enjoyed.

Later that resulted in ... surprise... burnout. Reasons are out of the scope, that's more related to personal traits. Still, after few years I've changed patterns. On the other hand, there's way less things to learn now. Not I mean there's not enough new tech, but once you know a lot of basics, you can learn necessary things on-demand easily, and just learn what's really interesting. And about same time I started working remotely.

With that, I've spend no more that 6 hours in a work, not more than 2-3 hours coding (with some occasional spikes with full-day coding once you have a very good vision how large project piece fits together). That was more than enough to be one of top contributors in ~100-people dev team. With good basement you spend less time on being blocked by some unexpected stupid things, and productivity grows. And there was lot of chatting, somewhat repetitive meeting, but that doesn't add much to the output.

Later with few job switches and with a lot life changes (wife, family, 2 kids) I've stopped at 2-3 hours coding plain in a more focused team, with minimal volume of meetings, and that works fine so far. With way more time left for other life.

As a developer I still know there's a lot of things can be done. There's always a lot of plumbing, a lot of "nice to have" features where (if I spend those extra 4-5 hours) I could deliver a lot of extra effort & results into sky. And I appreciate people who do that. While working in Yandex I've seen people way smarter than me processing dozens of tasks a day, making me feel uncomfortable about my productivity.

Still, that's my choice. I deliver quite good result which is appreciated. I estimate a week to implement feature which I could previously estimate as "I can implement it in 24 hours" (without a sleep). I choose to live more fulfilled live with my kids, my wife, friends, with more joy - and I'm glad to do that to common benefit.
ndmeredian
·hace 6 años·discuss
Depending on complexity and specialisation of your use that's what may work for unit testing:

1) Abstract real library with tech-agnostic interface to remove as much tech details as possible and focus on behaviour.

2) Create simplest in-memory dummy implementation for that interface, basically a mock.

3) Write a test spec for that interface behaviour (does xxx on yyy, returns zzz otherwise) and run it agains both real wrapped interface & mock to be sure they're consistent.

4) Make code to load mock in local testing env

5) Use real kafka when running it on a testing pipeline

Same way you could abstract various things - e.g. once I just abstracted proprietary services and locally flushed everything into local Postgres. You can emulate multiple services there - e.g. database, somewhat-usable queue, etc. And get some extra control nice for tests (e.g. make it to throw errors on your wish or add timeout to simulate net delays). That saved a lot of time for local development for me, without dropping quality.