←back to thread

388 points replyifuagree | 5 comments | | HN request time: 0s | source
Show context
nmstoker ◴[] No.37966119[source]
I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here.

However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy.

What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.

replies(9): >>37966150 #>>37966194 #>>37966480 #>>37966493 #>>37966648 #>>37966946 #>>37967117 #>>37967327 #>>37968617 #
1. orwin ◴[] No.37966493[source]
Don't ask for 30 minutes tasks unless you have to (it's breaking the prod or something), it's inefficient for everyone involved.

I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done while I'm on the subject. If there is nothing, I'll still take the full day (except if it's a project I know really well, in that case I take half), and take half a day to skim the code, and another half to update it (small comment, version upgrade, code improvement, renaming variables).

Push your IC to do the same. Imo it's more time efficient, the new-ish IC use that time to learn the older code, and in the end you will have less legacy issues (unless you make a big change).

replies(2): >>37966842 #>>37968866 #
2. rrr_oh_man ◴[] No.37966842[source]
Any downsides to this approach, from your experience?
replies(1): >>37968489 #
3. orwin ◴[] No.37968489[source]
I only have 10 month working like this, but yes. More linked to the code than to the approach, but sometimes I become easy to get lost on the 'I also need to fix this' and deliver the code _really_ late. My way of dealing with it is simple: at 4pm (I usually stop at 6), I take a 15 minutes break, talk with people (remote or not), make some tea and stuff, recenter myself. Then I check what can be merged into master before 6, scrap the commits I won't use, rebase the rest into one or two commits, then push and ask for review (once it was the '30 minute task' that pulled a lot of other shit, in this case I stopped and called the team lead/PM to redefine the card).

Then if I still have time I do reviews, administrative work and probably end the day there. The nature of our team make that time management suitable.

4. nmstoker ◴[] No.37968866[source]
Understood. I never do unless it were breaking prod or breaking major business processes.

Regular approaches, avoiding firefighting are essential to steady, stable states.

replies(1): >>37968884 #
5. nmstoker ◴[] No.37968884[source]
Sadly the need comes up too often.