Skip to content

Latest commit

 

History

History
48 lines (39 loc) · 3.8 KB

NON-TECHNICAL.md

File metadata and controls

48 lines (39 loc) · 3.8 KB

Career Happiness

Work at places that create margin for engineers to allow them to work on what's important, not just on what's urgent

This is impossible to know at the onset, but if you notice it becoming a trend where you work, leave.

Connect non-user-facing engineering tasks with business interests

If I'm not able to attend to tech-debt/code hygiene, become very demotivated. However, sometimes its just a matter of finding a way to incorporate those things into regular sprint work. Above all, ensure you communicate these technical issues and have a focused plan to improve them. Additionally, connect these non-user-facing engineering tasks with business interests. E.g., we need to work on reducing build times because it costs engineers X hours per week. Take measurements to prove the usefulness of the resources spent (e.g. we reduced the build time from 30mins to 10mins which saves engineers X hours per week). Most, if not all, engineering tasks are about more than developer happiness. They are about developer productivity. (Although, the former is certainly related to the latter.)

Early in your career, determine what type of work you find most fulfilling

I've found most engineers lie somewhere on the following spectrum: I'm happy hacking prototypes together and then moving onEverything I write must be proven code-correct

Know your weaknesses:

  • I’m poor at finishing things.
  • I need to break large tasks into smaller ones in order to stay focused.
  • I need to meet with others to discuss implementation strategies
  • I need to collaborate with design more on UI things EARLY
  • I need to have visibility into deadlines (not only for release date, but for PR-open date, code-complete date, stakeholder review date, merged date)

OSS

Don't let strangers negatively affect your mood or drive

It isn’t worth it. If you have the option to walk away, take it – utilize the unsubscribe button. Open source maintainers need to remember that users are not paying customers. We’re providing something to them for free, on our own free time.

Don't engage toxic people

With toxic people, you need to always be the bigger person. It sounds wrong, but what I try to do is to kill them with kindness. Somehow it has worked for me for many years. For example, if someone is annoying, I’ll try to be as open and kind about the situation. I make sure never to be sarcastic or talk down to them. The trolls feed on your annoyance and discourse, so when it’s not there, they’ll leave you alone.

Agile

  1. Break up tasks: Analyse the tasks at hand. If a task feels big, then break it up into multiple tasks.
  2. Have an estimating session: Estimate multiple tasks in the same meeting — Estimating a single task, out of context, makes it more difficult to understand the scope of each task.
  3. Compare Tasks: Pick two at random and sort in order of complexity. Continue picking more tasks and keep sorting. It’s ok if some are equal.
  4. Dish out points: You should now have columns of tasks. Number them using the Fibonacci sequence. The Sliding scale of Fibonacci bakes in an understanding of ‘risk’.
  5. Review: Is there anything missing? do any cards need to a tweak? can a column be dropped?
  6. Monitoring: Monitor how many points are completed each week/sprint. Also record how many points are being created and categorise these new tasks. This will allow us to understand how many points we complete a week (velocity) and why extra time may be needed. Week-by-week we should be able to see an updated prediction for the project.

Tasks should be assigned points on a fibonacci scale: 1, 2, 3, 5, 8, 13, 20.