Years of experience do not automatically make you a better programmer. I have met developers with a decade on the job who write the same mediocre code they wrote in year two. The difference between a good developer and a great one is deliberate practice — consistently pushing yourself outside your comfort zone with focused, intentional effort.
Following along with a tutorial gives you the illusion of understanding. Building something from scratch forces you to solve real problems. When you build a side project — a REST API, a personal finance tracker, a CLI tool — you hit walls that tutorials never show you: debugging cryptic errors, designing schemas, handling edge cases. That struggle is where actual learning happens.
Put every project on GitHub. Even if the code is rough, a public portfolio signals that you ship things.
Most developers only read code when fixing a bug. That is a missed opportunity. Reading well-written open source code is like studying how great authors write. Pick a library you use daily — Spring Boot, Express, Django — and read through its source. You will discover patterns you would never invent on your own.
Start small. Read a single module or utility class. Pay attention to naming, error handling, and organization.
Platforms like LeetCode and HackerRank are not just for interview prep. They train you to break complex problems into smaller, solvable pieces. When you practice with hash maps, trees, and graphs, you start recognizing which tool fits which problem.
Aim for two to three problems per week. Focus on understanding the approach rather than memorizing solutions.
Writing tests forces you to think about your code from the outside in. If your code is hard to test, it is probably poorly designed. Tests expose tight coupling, unclear interfaces, and hidden dependencies. Developers who write tests consistently produce cleaner, more modular code.
Start with unit tests for pure functions, then work up to integration tests. Solid test coverage gives you the confidence to refactor aggressively.
Your IDE is the most powerful tool you own — learn to use it fully. Most developers use maybe 20 percent of what IntelliJ, VS Code, or Vim can do. Learn keyboard shortcuts for refactoring, navigation, and debugging. Master the integrated debugger instead of relying on print statements.
Beyond the IDE, learn Git beyond add, commit, and push — understand rebase, cherry-pick, bisect, and stash.
Code reviews are not just a quality gate — they are one of the fastest ways to learn from senior developers. When someone suggests a better approach in your PR, do not just accept the change. Understand why it is better. Study the pattern so you can apply it next time.
Equally valuable: review other people’s code. Reading PRs from experienced engineers teaches you how they think about architecture.
Contributing to open source puts you in a professional-grade development workflow — branching strategies, CI/CD pipelines, code review from strangers who hold a high bar. Start with documentation fixes, small bug patches, or adding test coverage.
Learning a second or third language does not just expand your resume — it fundamentally changes how you think about code. A Java developer who learns Python discovers the power of simplicity. A Python developer who learns Go understands explicit error handling and static typing. Each language teaches principles you bring back to your primary stack.
Programming can be isolating, and isolation slows growth. Being part of a community exposes you to problems and solutions you would never encounter alone. Join language-specific groups on Discord, Reddit, or Slack. When you explain concepts to others, you deepen your own understanding.
Improving your coding skills is not about working harder — it is about working with intention. Build things. Read great code. Test relentlessly. Learn your tools. Engage with other developers. The developers who grow fastest are the ones who consistently practice outside their comfort zone and reflect on what they learn.
Few skills will impact your lifetime earnings as a software engineer more than knowing how to negotiate your salary. A single negotiation can mean tens of thousands of dollars per year — and that compounds over your career. Yet most developers accept the first offer they receive, leaving significant money on the table.
Walking into a negotiation without data is like deploying to production without testing. You need to know your market value before you can advocate for it. Use levels.fyi for detailed compensation breakdowns by company, level, and location. Cross-reference with Glassdoor and Blind. Look at total compensation — base salary, equity, signing bonus, and annual bonus.
For example, if you are a mid-level backend engineer interviewing at a Series B startup, check what comparable companies are paying. Having three to five data points gives you a defensible range rather than an arbitrary number.
This question comes up early, often from a recruiter on a screening call. The goal is to avoid anchoring yourself too low.
Deflect to their range: “I’d love to understand the full scope of the role first. Could you share the budgeted range for this position?” Many companies are now legally required to disclose this in states like California, Colorado, and New York.
Give a researched range: If pressed, say: “Based on my research, I’d expect total compensation in the range of $160K to $190K, but I’m flexible depending on the full package.” Set the bottom of your range at or above what you would actually accept.
Base salary is only one piece. Think of compensation as a system with multiple levers. When a company says the base is firm, explore other components:
Equity: Ask for additional RSUs or a higher stock option grant. At public companies, this can be worth more than base over time.
Signing bonus: Often the easiest thing to negotiate because it is a one-time cost. If you are leaving unvested equity, frame the signing bonus as offsetting that loss.
Remote work and flexibility: The ability to work remotely has real financial value — savings on commute, relocation, and time.
PTO and professional development: Additional vacation days or learning stipends are low-cost to employers but high-value to you.
The best time to negotiate is when the company has already decided they want you. After you receive a written offer, you have the most leverage. For performance reviews, start the conversation four to six weeks before the review cycle — give your manager time to advocate internally.
If you have a competing offer, use it respectfully: “I have received another offer at $X. I prefer your company because of the team and mission, but I want to make sure the compensation is competitive.” This is providing data, not making a threat.
Negotiation is a skill, and you get better with practice. Before the call, rehearse your key points. Know your target number, your walk-away number, and two or three reasons why you are worth it — specific projects shipped, revenue impacted, systems improved.
Keep your tone collaborative. Phrases like “I’d like to find something that works for both of us” keep the conversation productive. The recruiter or hiring manager is often your ally — they want to close the hire.
Having a clear walk-away number protects you from accepting something you will resent. If a company cannot meet your minimum after good-faith negotiation, thank them and move on. Your leverage only increases as your skills and experience grow.
Salary negotiation is not about being aggressive — it is about being prepared. Do your research, understand the full compensation picture, time your ask wisely, and practice the conversation. A well-negotiated offer at the start of your career can be worth hundreds of thousands of dollars over a decade. You owe it to yourself to ask.
August 7, 2019At some point in your software engineering career, you will deploy a bug to production, fail a technical interview, or watch a project you poured weeks into get cancelled. Every senior developer you admire has a graveyard of failures behind them — and those failures are exactly what made them senior. Learning to deal with failure is about building the mindset that turns setbacks into growth.
Every failure carries information that success never will. When a deployment breaks production, the post-mortem teaches you more about system resilience than a hundred successful releases. When your pull request gets rejected with a wall of comments, each comment is a lesson from someone who has already made the mistake you are about to make.
The shift happens when you stop reading failure as “I am not good enough” and start reading it as “Here is what I did not know yet.” A failed deployment means your testing strategy has a gap. A rejected PR means your understanding of the codebase has a blind spot. That is valuable data.
Deploying a bug to production is a rite of passage. Maybe you pushed a migration that wiped a column, or your null check missed an edge case that crashed the checkout flow. Your stomach drops. Slack lights up.
Here is what matters: how you respond. Roll back or fix forward immediately. Communicate clearly — tell your team what happened, what the impact is, and what you are doing about it. Then write an honest post-mortem. The developer who caused the outage and then wrote the runbook that prevents it from happening again is the one people trust.
Few things are more demoralizing than building something for weeks only to hear “we are going a different direction.” Business priorities shift. Market conditions change. A competitor launches first. None of that reflects your ability as an engineer.
What you built still taught you something — a new framework, a better pattern, a deeper understanding of the domain. Extract those lessons deliberately. Keep code snippets, note architectural decisions that worked, and move that knowledge into your next project. Nothing you build is truly wasted if you learn from it.
Failing a technical interview feels personal because it is a direct evaluation of your skills. You blanked on a data structure question or talked yourself into a corner during system design.
Interviews are a narrow, artificial test. They measure your performance under pressure on a specific day, not your actual engineering ability. But they do reveal gaps you can close. If you froze on tree traversal, drill tree problems for two weeks. If your system design was shaky, study how real systems are built. Turn the sting of rejection into a focused study plan.
Tough code review feedback can feel like a personal attack, especially early in your career. Comments like “this entire approach needs to be rethought” hit different when you spent three days on that approach.
Separate your identity from your code. The reviewer who pushes back hard is often the one who cares most about the codebase. Ask questions instead of getting defensive: “What approach would you suggest?” Every tough review you absorb without ego makes you a stronger engineer.
Resilience is not something you are born with — it is built through practice.
Keep a failure log. Write down what went wrong, why, and what you learned. Reviewing it quarterly shows you patterns and proves how far you have come.
Set a recovery window. Give yourself permission to feel frustrated — for an hour, for an evening — then shift into problem-solving mode.
Talk about failures openly. In retrospectives and mentoring conversations, normalizing failure makes everyone braver.
Study other people’s failures. Read post-mortems from Google, Cloudflare, and GitLab. Even the best teams ship bugs and break things.
Failure is not the opposite of success in software engineering — it is the cost of doing meaningful work. Every production incident, cancelled project, failed interview, and tough code review builds the judgment and resilience that separates senior engineers from everyone else. Do not run from failure. Run through it, document what you learned, and keep shipping.
August 5, 2019After fifteen years in software engineering, the most counterintuitive lesson I have learned is this: the best thing you can do for your code is step away from it. In an industry that glorifies hustle culture and late-night coding sessions, rest is not a weakness — it is a strategic advantage.
Every experienced developer has lived this scenario. You have been staring at a bug for three hours, added print statements everywhere, reread the stack trace dozens of times — then you go for a walk, sleep on it, and the solution appears almost instantly the next morning.
This is not coincidence. Neuroscience calls it diffuse mode thinking. When you step away from focused problem-solving, your brain continues working on the problem subconsciously, forming connections your conscious mind could not. Some of my best architectural decisions have come to me while cooking dinner or running errands. Stepping away is not giving up — it is letting your brain do its best work.
Burnout does not arrive with a dramatic crash. It creeps in slowly. You start dreading pull request reviews. Simple tasks feel overwhelming. You become cynical about projects you once enjoyed. Your code quality drops, but you compensate by working longer hours, which only accelerates the cycle.
In software teams, burnout is especially dangerous during crunch periods. I have watched talented engineers push through weeks of overtime only to introduce more bugs than they fixed. Fatigued developers write fragile code. Watch for warning signs: persistent irritability, difficulty concentrating, loss of motivation, and withdrawal from your team.
Using your vacation time is not selfish — it is responsible engineering practice. When you take real time off and fully disconnect, you return with fresh perspective. I have come back from vacations and immediately spotted architectural problems that were invisible to me before.
Teams also benefit when individuals take PTO. It forces knowledge sharing, exposes single points of failure, and builds resilience. If the system falls apart because one person took a week off, that is an organizational problem worth discovering sooner rather than later.
The strongest engineers I know have rich lives beyond their IDE. They rock climb, play music, paint, or restore old cars. Hobbies outside of coding are not distractions — they are what keep you sharp.
Creative and physical pursuits activate different parts of your brain, reducing cognitive fatigue. They also build problem-solving skills that transfer back to engineering. If your entire identity is wrapped up in being a programmer, a rough quarter at work can feel like a personal crisis. Diversifying your sense of self builds emotional resilience.
Rested developers ship better software. Studies consistently show that working beyond 50 hours per week leads to diminishing returns. Build intentional breaks into your workflow — use techniques like the Pomodoro method, take a real lunch away from your desk, and end your workday at a consistent time. These small habits compound into significantly better output.
Set hard boundaries on work hours. Close your laptop at a set time and do not reopen it.
Schedule downtime like you schedule meetings. Block time for rest, hobbies, and exercise.
Practice real disconnection. Turn off work notifications on weekends.
Use your PTO. Plan at least one extended break per year where you fully unplug.
Normalize rest on your team. When senior engineers model healthy work-life balance, it gives everyone else permission to do the same.
Rest is not something you earn after the work is done — it is part of the work. The most productive, creative, and sustainable engineering careers are built on a foundation of intentional recovery. Protect your rest the way you protect your production environment: with clear boundaries, monitoring, and zero tolerance for compromise.
August 5, 2019Most developers think career growth is purely about technical ability — better code, deeper system knowledge, faster debugging. But one of the most underrated skills that separates senior engineers from everyone else is excellent reporting. The ability to communicate status, progress, risks, and outcomes clearly is what gets you trusted with bigger projects and leadership roles.
The first rule of reporting is understanding who you are talking to and what they need. A standup update for your engineering team is not the same as a project status email to a VP. Your team wants technical specifics: “I finished the API integration for the payments service and opened a PR. Today I’m tackling the retry logic for failed webhooks.” Your VP wants outcomes and risks: “Payments integration is on track for Thursday’s release. One open risk — the third-party sandbox has been flaky, which could delay testing by a day.”
Speak their language, not yours.
The daily standup is your most frequent reporting opportunity, and most engineers waste it. A strong standup follows a simple formula: what you completed, what you are working on next, and any blockers.
Bad standup: “Yesterday I was looking at some stuff with the database and the queries were slow so I was trying to figure that out.” Good standup: “Yesterday I identified the slow query on the orders table — missing index on customer_id. Deployed the fix to staging. Today I’m running load tests to verify. No blockers.”
Be specific and be brief. Your team should walk away knowing exactly where you stand.
When production breaks, the postmortem is one of the highest-visibility documents you will ever write. A strong incident report includes: a clear timeline, the root cause, the immediate fix, and concrete follow-up actions with owners. For example: “At 2:14 PM UTC, the auth service began returning 500 errors due to an expired TLS certificate. The on-call engineer rotated the certificate by 2:38 PM. Follow-up: automate certificate rotation by March 15 (assigned to platform team).”
Keep it blameless. Focus on systems and processes, not individuals.
When reporting on project status, structure your update around what was accomplished, what is remaining, and what risks need attention.
For leadership: “The data migration is 70% complete. Customer and order data migrated successfully. Product catalog starts next week. Risk: legacy data has inconsistent formatting in 8% of records requiring manual review. We added two days of buffer.”
Quantify wherever possible. “We are making progress” means nothing. “We closed 14 of 20 tickets this sprint” tells a clear story.
The best engineers do not wait to be asked — they push information before anyone has to pull it. If a deadline is at risk, flag it early. A message like “Heads up — the API migration is taking longer than estimated because the legacy endpoints have undocumented rate limits. I adjusted my estimate to Wednesday instead of Monday and here is my mitigation plan” is infinitely better than silence followed by a missed deadline.
Proactive communication signals ownership and reliability. It is the difference between being someone who manages their work versus someone whose work has to be managed.
Use a consistent structure for recurring updates — people process information faster when the format is familiar.
Lead with the conclusion — state the status first, then provide supporting details.
Keep it honest — surfacing risks early gives your team time to respond.
Write it down — follow up verbal updates with a written summary in Slack, email, or your project tracker.
Review before sending — re-read and cut anything that does not add value.
Excellent reporting is not about writing more — it is about communicating the right information to the right people at the right time. Whether it is a 30-second standup, a post-incident review, or a quarterly project summary, clear and structured reporting makes you the person others rely on. And in software engineering, being the person others rely on is exactly how you build a career that goes beyond writing code.
August 5, 2019