Engineer advices
Career Evolution
Youth
When you’re young as a software engineer, it’s the perfect time to learn as much as possible and be open to new technologies and methodologies. The earlier in your career, the more you should strive to learn across different languages, frameworks, and problem spaces to build a robust repertoire while your mind still has that sponge-like absorption ability.
Diversity
Alternating between startups and large corporations brings complementary strengths. Startups provide autonomy, spark creativity through challenging projects that propel your career. Large companies enable you to accumulate invaluable knowledge on scalable processes to eventually bring back to startups. Startups need some of the seasoned experience from big companies, while large groups need the fresh flexible thinking of startups.
By accumulating these diverse experiences, you make yourself an extremely versatile and valuable asset. The cross-pollination of lessons learned across both types of environments will expand your skills and make you highly adaptable to any new role or challenge that comes your way.
Experience
| Stage | Description | Core Question | Pursuits | Planning Horizon | Team Interactions |
|---|---|---|---|---|---|
| 1. Foundational Skills | Feeling unequipped when facing a new problem and focused on finding any solution that works | ”How can I make this work somehow?” | Accumulating breadth of technical knowledge | Days/Weeks | Individual or pair programming |
| 2. Established Practices | Developing familiarity with standard tools and best practices that provide a methodological toolkit. | ”Why is approach A better than approach B here?” | Learning industry best practices | Weeks/Months | Team collaboration |
| 3. Contextual Problem-Solving | Drawing on accumulated experience to quickly size up a problem and design an effective, tailored solution using the right tools. | ”What is the business context and use case we need to optimize for?” | Gaining cross-domain expertise | Months/Quarters | Cross-team and cross-functional collaboration with product stakeholders |
Asking questions
Meetings frequently include many acronyms that can be confusing, especially for those newer on the team. Although you may hesitate to ask for clarification, remember that others likely have the same question.
Speaking up can help level up understanding for everyone. By being a gatekeeper for good comprehension in the room, you’re enabling the team at developing shared clarity on terms and concepts.
”What problem are we trying to solve?”
Similar to the XY problem , it can be a powerful question helping to get to the root cause and ensure solutions address real needs. It can provide clarity at multiple levels:
- Clarifying requirements
- Evaluating if a technical solution is solving the right issue
- Prioritizing the most important problems to focus on
- Providing additional context to the person asking
The goal should be mutual understanding, not discouraging or shutting down discussions. With the right intent, “What problem are we solving?” can lead to better solutions by unpacking assumptions and aligning on the origin of issues.
Debating solutions
1. Data availability
Do we have the right folks and enough information to have a constructive debate? Make sure the context around the problem we’re trying to solve is clear to everyone. If not, can we bring in someone who can provide more context? Do we have technical experts with experience in this area available, or has the necessary research been done already?
2. Alignment
Identify the communication styles of the people involved in the debate. Depending on individual personalities and experience levels, people may rely more on intuition or bad memories than concrete technical details when evaluating solutions. In that case, you can help focus the conversation by visually mapping out a comparison of the different solutions on a whiteboard or screenshare. This keeps the debate centered around objective criteria.
3. Wrap-up
Verbalize a summary of the key discussion points and decisions. This helps crystallize and validate understanding. It also allows new insights to emerge, like rubber duck debugging . Afterward, document the summary clearly in writing async. This saves time for all participants and creates an artifact of the meeting outcomes.
No consensus?
In rare cases where reaching consensus is difficult, pick your battles and evaluate if the decision is worth debating by considering:
- Is it an implementation detail you can let slide?
- Is it a valid alternative approach that still achieves the goal?
- Is it a moderately important but non-critical point you accept but document?
- Is it something you need to veto? Like team wanting to adopt a new language on a tight deadline when your shop has standardized on another, with no outstanding benefits that justify the change
Respecting the process
Follow each step of the process fully - don’t try to jump right to the implementation.
1. Understand requirements
Take time to thoroughly understand the problem requirements first.
2. Brainstorm solutions independently
On your own, come up with potential solutions and note their pros and cons. Skipping this step can lead to copy-pasted solutions designed for a different use case, fewer creative and out-of-the-box ideas, and overall less learning
3. Discuss with colleagues
Chat with coworkers to get new perspectives. See if someone has already solved it or worked on a similar problem where resources could be shared.
4. Implementation
Finally, move forward with implementation based on the full context gathered from the previous steps.
Spending time upfront on steps 1 and 2 can save significant time in the long run and help avoid needing to rewrite the solution later on.
More
- When designing system components, aim for each one to “do one thing and do it well”. Simple focused modules are more understandable and reusable.
- Once you feel confident on requirements, don’t overthink - move to implementation. Experimenting with solutions teaches more than procrastinating. Failing but learning is better than inaction.
- Continuously ask yourself - what would make this project better? Think of improvements both for the product and technically.
- When evaluating new technologies, consider maturity stage and adoption trends. Don’t adopt bleeding edge tools too early, a.k.a. Hype-Driven Development , but recognize growing momentum in time to ride waves upwards pragmatically.
- Let context guide your decision-making on things like system design, languages, frameworks, infrastructure. There is no universally “best” choice - tradeoffs exist and can depend on the company size, project requirements, available resources, budget, time, etc…