2020-10-24

Prove it

  • Proving the work you have done is valuable is half the work. This is a frustrating reality. Many engineers set expectations too low for this half of the work. They fall into a trap of thinking that people will understand the value of their software if it is good. The problem is, only other engineers appreciate good software, and even then some of them will miss the point. You are thinking about your problem everyday, so of course the value is clear to you. It's not so to other people, especially those who aren't deep in your space.
  • This is why methodologies in [[building an audience first]] are becoming so popular. Following [[lean startup]], you don't start writing code until it has been established there is a significant need. An engineers life is easier if you do the convincing up front, then deliver.
    • This does require that you must actually be able to deliver
  • When you flip it the other way, you put yourself at huge risk of failure and frustration. What if you do all the technical work then fail to convince your boss that it is valuable. You'll be upset your boss can't see what you see... but you shouldn't have done the technical work before he was convinced (unless you established it was a risk worth taking)
  • Even when you do have your boss or customers convinced, they still need some kind of report showing metrics for money saved, time saved, value added, etc. Your bosses have bosses, your customers have bosses, and at the end of the line somewhere is a person whose only interest is increasing revenue and reducing cost (thanks [[Patio11]] [[Don't Call Yourself A Programmer, And Other Career Advice]]).
    • Accept you're going to have to create this material. Accept it is just as much work as any of the technical things you do (probably more important)


My Linked Notes

One last thing

If you liked these notes, hit me on Twitter!