This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the collaboration category.
Last Updated: 2024-11-23
Book by Swizec Teller
This is the nature of programming. Chill and don't freak out.
Basically: Can you carry a project from start to finish without your manager's input? Asking other people for assistance, testing, documenting, doing QA and working with QA team, deploying, etc.
Ultimately this saves the company money by force-multiplying.
That certainty that stuff is happening and that when stuff stops happening they’ll know immediately means the world to your manager. When you come to them and say “Yep gonna be done tomorrow” or you say “Nope won’t be done, here’s why”. It relieves anxiety like you wouldn’t believe.
Ideas:
Start doing things (and initiating things) that improve things overall for the company and makes the team more efficient.
They care about results - focus here.
Don't think about how much time or effort it takes to do something. Consider instead how much value it provides.
This is how to feel good (and justified) in asking for high rates.
If you have savings/lots of options, then you are able to push harder about earning more because you can walk away.
Companies care about the systems and tools you put in place to make the whole engineering team run better, do more, and make bank.
Make companies want you - not just a code monkey
Client testimonials trump all. Collect those.
How well must you engineer something you're throwing away 3 days after deploy because customers hate it?
You don't know if you (or the company) will be alive in 6 months. Work around the issues for the most past. Figure out the duck-tape charade.
Fix things when they hurt or break.
When the business people say best they often mean good enough When they say guaranteed, they often mean unlikely.
Terrible: Ask how can I use team to get more done?
Good: How can I help team get more done?
Great: How can I create systemic changes that remove crap my team have to deal with?
Amazing: How can I build tools that help team?
If you grab a project, it will get done. No matter what.
How will this code adapt to changes in how this task evolves? What does this code encourage others to do? How does this code encourage other programmers to use it? How will I understand this code in 5 months? How will a busy team member jumping around grok this? When will this code stop being good enough? How does it scale? How does it generalize? What hidden dependencies are there?
A fake is a simplified implementation of the real thing, maintained by the same team for API parity
Going from 2.8.1 to 2.8.2 is easy. From 2.8 to 2.9 harder. From 2.8 to 4.0, much harder.