Ask HN: How did you scale yourself as an engineer? - wowsig
======
itamarst
Learn to prioritize, and value your time. You're not going to get much more
done by working an extra 5 hours. Doing the same thing over and over again
without getting tired is what computers are good at, humans have other skills.

So given limited time, you want to make sure you're spending it in way that
produces the most:

1\. Are you working on something actually worthwhile? This is a very personal
decision, about your own values. More here:
[https://codewithoutrules.com/2017/08/07/do-something-
useful/](https://codewithoutrules.com/2017/08/07/do-something-useful/)

2\. Are you solving the right problem, or just a symptom?

3\. Are you solving the problem the best way?

4\. Are you doing repetitive work that can be automated, as sheraz notes?

In the end you can't scale yourself beyond a certain point, but you can
increase your impact by focusing on the really important things. More here:
[https://codewithoutrules.com/2016/08/25/the-01x-programmer/](https://codewithoutrules.com/2016/08/25/the-01x-programmer/)

------
sheraz
Automation, templating, and and knowing when to ask for help.

1\. Automation I automate provision environments, deployments, tests, and the
command line. Pretty much whatever I can in a reasonable amount of time.

2\. Templating I have a few project templates that already have the above
automations scoped out. My ci/cd script, a makefile with common tasks,
dockerfile skeleton, sensible playbooks. This lives in a skeleton git repo and
cookiecutter.

3\. Asking for help I'm active on stackoverflow ,various slack communities and
mailing lists. This is critical in moving my work along at a healthy clip.
There is a lot to be said for figuring it out on your own, but I'm more
concerned with delivering value than being academic or pedantic about my
implementation.

These are the skills and behaviors I try to hire for and the ones I try to
have for myself.

------
twunde
Learning to document well. I've written runbooks for tasks that would involve
me reading through the code for a day and brought the time involved down to 5
minutes (and that can be handed to junior engineers or new hires). I've also
seen really great documentation written by a senior engineer that cut days off
of tasks, long after that engineer had left.

------
SirLJ
As I know what kind of engineer I am, I am really afraid to go to the doctors
:-)

