3 ms·

Ask HN: How did you scale yourself as an engineer?

12 points by wowsig 9y ago

sheraz 9y ago
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.
itamarst 9y ago
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/
twunde 9y ago
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 9y ago
As I know what kind of engineer I am, I am really afraid to go to the doctors :-)

12 points by wowsig 9y ago

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.

itamarst 9y ago

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/

twunde 9y ago

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 9y ago

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