Pranav Kasetti

Why make this post?

I am an ambitious developer, always looking to improve and develop great apps. As developers, we always face new challenges during our day job, and no situation can ever be fully perfect. That being said, I've always made an effort to maintain a positive mindset when facing problems out of my control.

My challenges revolve around my goals:

1. Ship side projects.
2. Blog high-quality technical articles.
3. Speak at meetups / conferences.
4. Keep up to date with the industry.
5. Perform highly at work.

These are ambitious goals, and thus achieving all of them requires a lot of planning and strategy.

In this scenario, I have toned down my expectations and broken down the goal into more realistic sub-goals.

Less is more.

I plan to develop a long-term mindset as a developer, so that I don't burn out. I need every advantage I can get to achieve my goals which is why I think it's really helpful to work in a great software development team.

In this post, I devise solutions to 5 challenges I face trying to achieve my goals (as a self-taught developer).

1. Reading too many blog articles, not coding enough (Tutorial Hell).
2. Copying too much from StackOverflow (Copy-Paste programming).
3. Being over-accommodating with estimation (Rushing).
4. Formulating realistic deadlines for side projects (Planning).
5. Navigating technical debt (Work).

Tutorial Hell: Reading too many blog articles, not coding enough

This is a really common trap, and I've seen even senior-level developers fall into it. The fact that even seniors struggle with this trap shows you that you can still be a good developer with fewer side projects. Either that, or I'm aiming too high (unlikely :p). Note that reading lots of blog articles for me is usually a byproduct of not working on side projects instead. The main solution here revolves around a "mindset shift" and "aiming higher".

Solution(s):

1. Don't blame yourself for making this mistake because you hadn't been exposed to outstanding senior-level developers. Many developers never recognise this problem. Try to surround yourself with high achievers and don't follow people who don't align with who you want to become.
2. "Mindset shift": Always live outside your comfort zone!! 🚵‍♀️ When we get too comfortable, we stagnate on side projects and procrastinate. Take complete ownership to achieve your goals, and don't stop to think about what you've achieved, even if you have surprised yourself. When you notice you're procrastinating, and starting to be egotistical praising your accomplishments endlessly, remind yourself there is more to do. Set a more ambitious goal, for example, a GitHub project and try to get 10 stars. Aim higher 🎯. Some people have over 100k reputation on SO and have millions of blog followers. Some comfort is fine, but it's a warning sign when you start procrastinating. You're not a rockstar developer at the moment by most measures, so don't get cocky. Pat yourself on the back for reaching 6k SO rep and move on. Measure yourself by real-world metrics such as the number of your GitHub stars, SO reputation, and side project ARR. One of my goals is to reach 10k reputation on StackOverflow - that's a LOT of work to do! You don't have time to be complacent. Balance comfort with throughput by being mature and measuring yourself against your ambitions.
3. Fix the problem by shipping side projects. I delivered side projects in the past when I committed to a firm deadline, and coded daily rather than read articles. Set a 1 month target, code daily and just do it.
4. Limit article reading to a need-to-know basis.
5. When reading articles, try to extend what you learn in each post with your own take on things. Don't blindly copy and paste, rather understand and adapt the code.

TIP: There's no finish line in the race to excellence. 😃

Copy-Pasting: Copying too much from StackOverflow

Every developer uses StackOverflow, so don't worry about that. The best developers however try to limit their usage and derive things from first principles. As with most engineering, it's a trade-off. You can't always have shiny new prototypes to build or the licence to learn everything you want in your day job, so be realistic. Balance Googling with independent learning.

That being said, copy-pasting from SO need not be avoided completely. I now aim for a 70/30 split, and this is a good balance for learning + velocity.

The main principle behind independent learning is to have a beginner's mind and stay present when coding.

PLAN: Develop intuition for learning quickly on the job by documenting what works and doing your best.

Solution(s):

1. It's impossible to NOT use SO whenever you're learning something new, so don't listen to anyone who tells you otherwise. Don't blame yourself.
2. Use Dash instead of Googling or going on SO. Ultimately, derive information from the established source documentation or authority.
3. Learn Google-fu to search for the right keywords, and reference recognised authority sources.
4. Reuse Coding Snippets.
5. Ship side-projects and you'll naturally learn on the go without needing to SO everything. Consistency is key.
6. Don't worry about copy-pasting code if you adapt the code to your needs and understand what you are writing. Copy-paste programming is fine, NOT Cargo cult programming.
7. Join a team who are passionate about software craftsmanship.
8. Push back on estimates if you need to learn on the job.

Rushing: Over-accommodating with estimation

When you're in a job, there is always going to be pressure to deliver features to a deadline. However, you don't have to cave in to it.

Solution(s):

1. Push back if the estimate is hard to achieve, and give a reasonable estimate in response. Balance quality with velocity.
2. Manage expectations with open communication. Raise blockers early and keep talking out loud.
3. Develop your coding ability with consistent deliberate practice.
4. Practise saying "NO" to build up your assertiveness.
5. Pay attention to how long it takes you to finish a feature to high quality until you've developed your estimation muscle.

Planning: Realistic deadlines with side projects

Working on a project can only drain your creativity and sanity if you let it.

I found working with legacy code extremely painful because I was not working with a passionate team. I looked forward to learning something new after work via side projects when working on legacy projects in my day job. Even with a fun job, side projects are hard to complete, but side projects are good in general.

Doing side projects can offer satisfaction, but only if they are realistic. Ambitious side projects after work would often overwhelm me and I got frustrated with the pace of my development. So, how can we follow through on side projects even when jobs are intense?

Solution(s):

1. Join a talented, like-minded team that ships independent side projects / blogs. It's a well-known idiom that you will become most like the people you associate with, so do your best to get into a strong team + company. Good jobs improve your baseline performance.
2. Do something that excites you! :D If you are truly passionate about the project or about learning, you'll find a way to do it even when you are tired. DON'T suffer or fail silently, put yourself out there and keep on doing things. Take radical action to solve radical problems.
3. Plan your main goal for the next 3 months, weekly targets and then your daily goal. The important thing is to focus on doing ALL daily tasks when they have been set. Don't give excuses because they will snowball into bigger failures. Just do it.
4. Pace yourself with side projects: ~2-3 hours daily in your spare time. Develop a routine, either in the mornings or evenings to get work done. Start strong and work hard but don't go over 3 hrs because you will burnout. Strong routines are what drive success, again by upleveling your baseline performance.
5. Don't take on extra work, events or commitments if you're falling behind on side projects.
6. Set and stick to your deadline no matter what. If you don't set a deadline you'll almost certainly end up drifting. Being radically honest, that's happened for several years to me (unconsciously) and has been the main reason I failed to ship side-projects after getting started. Admit the mistake and learn from the experience so that it NEVER repeats. The hardest step is facing up to your failures, and setting up a process to avoid it in the future... Set SMART Goals!! 🎯
7. Maintain a balanced, healthy lifestyle regardless of velocity to ensure you don't burn out. This means giving importance to seemingly unimportant tasks: doing the laundry, cooking, cleaning, exercise and shopping. You are NOT a machine, so treat yourself as someone who you can negotiate to work with effectively.
8. Recognise that Rome wasn't built in a day. Be patient, consistent and value your daily input. Try to be disciplined to get your duties done no matter what you feel like. It's hard for everyone to get started and achieve these goals, so don't feel sorry for yourself :P. The hardest part is getting started, so just start. It's not too late!! :D You can do anything you set your mind to. As Joel mentions, it's hard even for him to write code daily, so don't set unachievably high standards to write beautiful code daily. If you wrote any side project code today, that is a success. 🚀

Work: Navigating technical debt

Don't worry if there's a lot of legacy code, because it's NOT your responsibility to fix other peoples' mess. Code slowly if you have to, even if it annoys people. Learning how to handle legacy code is a fundamental engineering skill.

Solution(s):

1. Resist your impulses to refactor everything when you notice legacy code. It's pragmatic to spend 20% time refactoring and prioritise delivery. That doesn't mean you shouldn't log issues for the future.
2. Push hard at the start of a project to establish a good routine + workflow, sweating the essentials. The essentials are side projects and regular StackOverflow contributions. Don't worry if you can't do everything else.
3. Coach at codebar regularly to let off steam after work.
4. Advocate for testing + refactoring in future sprints.
5. Post on (Slack?) groups occasionally to let off steam with talented developers. Don't worry about staying on top of all posts though.
6. Focus more on writing to keep your sanity. Before or after a meeting, write down all your thoughts and articulate what you want to say. Writing captures thoughts in a way that you couldn't do in the meeting. Hopefully, over time you will internalize a lot of that.
7. Be firm when providing quotes. Be conservative when estimating (add 30% padding) to alleviate pressure.
8. Be proud that you did your tiny bit, and join a team that is also proud of you. Good teams advocate for software craftsmanship. If you aren't enjoying work without a talented team, quit your job and find a better company. It's not worth the pain in the long-term.

Summary

In summary, problems don't need to be tolerated in software development or in general. It's not the problem that counts, it's how you respond and manage complexity. We can see the problem from two angles: one from resignation, and one with positivity.

I choose to always have a positive and an abundance mindset.

Think Positive!! :D

I hope these strategies are useful. Work can either be a chore, or we can choose to find the pleasure in seemingly tedious work. I plan on applying these strategies in my future projects to stay sane. I may update the tips if I find anything else helpful.

Keep moving forward, that's how winning is done.

Ps. Maybe I'll see you at WWDC '22 or NSLondon. 😉

Resources

1. Fire and Motion