Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I feel like this is mostly related to eliminating miscommunications.

A lot of people just jump right into developing without asking the right questions first. Especially when given ambiguous orders.



For real. I’m a contractor that bills by the hour which means I have a pretty good understanding of cost of features.

At a previous client I got a ticket that would mean rewriting a large part of the application, to the tune of €10k. Something didn’t sit right with me and I started sleuthing around the org chart, asking relevant people questions. The €10k ticket became €0.5k in research and two-line css fix + different copy in the UI


so how did they reward you for the cost savings you helped them to yield?


By renewing my contract for 6 more months.

I am a contractor, I get paid for hours spent. If I got paid by money saved I’d be a consultant. Small but important difference and wildly different business models.


The difference is clearly explained but then the contractor (@brtkdotse) does the work of the consultant but as a contractor and reduced their own billable hours.

Business renewed the contract because they're realizing they're getting both roles for the pay of one.


you did the work of a consultant. you surely have it in you. take the next step


I like to ask my colleagues often, brainstorm a bit with them etc when solving problems. Usually after pondering the issue a bit I get an idea of what a good solution would be, but often I can get valuable input from my coworkers.

Maybe I've missed an important corner case. Maybe my coworker has worked on something similar or relevant and has some code or technique I could use. Maybe I've been overthinking it and a stop-gap is better until we can make a more informed decision.

Sometimes just a tweak can make a significant difference, other times I end up going a completely different route.

I'll also email or phone customers if I sense a X/Y problem, or if I don't fully get their feature request or bug description. I'm not a domain expert and it's good to have context.

All in all, indeed it's usually a good idea to not jump straight into it. Mull it over, talk a bit with someone.


Putting in time to avoid unnecessary work caused by miscommunication or lack of communication could be seen as an attention focused workflow: It is about making sure attention and work is focused on what is actually the problem, and not everything else surrounding it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: