New developers start their careers with a limited grasp of the ‘what’, the basics of how to write code in a given language and tech stack, but the deeper understanding of the ‘why’ and how to evaluate potential solutions and pick the most effective solution given known constraints comes much later with experience.
Experienced developers have knowledge of what they’ve seen work and not work from past development projects and can use this knowledge to make educated decisions. Given any problem, having seen multiple solutions applied on past projects allows you to draw from that knowledge of seeing what has worked and not worked and evaluate what solution is the better option when you see this problem again (or something similar).
Experience and knowledge is hard to pass on from one developer to the next. Programming techniques like iteration and conditional statements can be taught and easily learned, but an appreciation of why solution A is more effective than B is harder to convey, usually because the reasons why one solution is better depends on the context and an understanding of the current constraints that you need to work with. Being able to identify what’s important and what is not is a skill that more experienced developers develop over time, but it’s hard to teach.
Experienced developers add obvious value to any project or team, they provide leadership and the benefit of being able to make informed decisions based on their prior experience that lead to better outcomes for the business with a higher degree of certainty (compared to randomly picking a possible solution without knowing if it’s feasible or the most effective option or not).
The problem we have as an industry is that we still haven’t worked out an effective approach for conveying this experience to other new developers. You can gain experience by putting in the time and effort by working on a variety of different software development projects, but there doesn’t appear to be any easy fasttrack approach to package this information and hand to another developer. Can software development experience be ‘knowledge transferred’ to another developer? Maybe not. Maybe you just have to invest the time to gain experience the hard way.
Misunderstanding or under valuing the experience that an experienced developer brings to a team is a common mistake of someone who does not fully appreciate the complexity of software development. All developers are not equal, and one developer cannot be equally exchanged for another. If we can find an effective approach to easily fastrack the passing of experience from one developer to another, this would massively accelerate the growth of new developers, but maybe the reality is experience just has to be gained the hard way.
A question frequently asked by new developers is what to learn, how much to learn, and how do you know when you’ve learned enough?
Learn what you need to solve the current problem and then repeat for the next problem.
Don’t think about his as a finite set of knowledge that you need to learn and then that’s it, that’s the end. That’s not how it works. There’s always something new to learn, and there’s always something you’ll find that you don’t know.
Adjust your mindset to keep this in mind and you’ll be ok.
A common question asked by new developers starting out, especially during the first few months of learning, is ‘when does it start to get easier?’
The reality is it never really gets ‘easy’, but with experience it does get easier. When you’ve seen enough similar problems and previously worked out solutions before, that knowledge and experience helps you approach new problems.
A completely new problem that you’ve never seen before obviously takes more time and effort to work out an appropriate solution. A problem that you’ve already seen before takes less time because you’re able to apply the previous knowledge and solution.
The point where things start to get easier is where you’re able to pull from previous similar problems that are different from the current problem you’re working on, but enough knowledge and previous experience helps to find a solution to a completely new problem.
When do you reach this point? It varies for everyone, it depends what you’re working on. If you’re working in an environment where you’re working on very similar problems day after day, you’re not encountering enough variety to grow your experience so will take you longer. If you’re lucky enough to be working in an environment when you’re exposed to a broad range of problem types, then you’ll develop your experience quicker.
Once you’re familiar with building a solution for a given problem, as you’re learning new languages, frameworks, libraries or whatever is your current focus, there’s no reason why you have to build something completely new when you’re learning something new. Learning to solve problems is valuable and essential, but if your current goal is to build some experience with a new framework for example, there’s no reason why you shouldn’t rebuild something you’re already familiar with.
For example, if you’ve come across any of my posts before, you’ll know I’ve been spending a huge amount of time writing code around solving and generating Sudoku puzzles. While this has been an interesting exercise in itself, the real goal was to use it as set of related problems for practicing building apps with React and AWS Lambdas.
Even for the frontend I’ve gone through a couple of variations:
The initial frontend app was React with Redux, and it’s served from a public S3 bucket here: http://react-sudoku-solver.s3-website-us-west-1.amazonaws.com/index.html . The source for this app is here: https://github.com/kevinhooke/sudoku-solver-react-app
I then redeployed it using a CloudFront distribution, with a Route53 record using my domain name, that’s here (it’s still the same app at this point) : http://sudoku-solver.kevinhooke.com/
Recently I rebuilt it using Redux instead of Flux. I don’t have that deployed anywhere yet, but the source for that app is here: https://github.com/kevinhooke/sudoku-solver-react-app-with-redux
I was planning on updating the app to download pre-generated puzzles. That part took me off on a wild goose chase, on working out how to generate puzzles and grade them with a human solver to assess their difficulty. Now I’ve got that part working, I can come back to the frontend app again.
This app, the frontend and the backed solver, generator and grader has kept me busy for month. You don’t have to build something new everytime, if you’re struggling for ideas for personal projects, it’s ok to rebuild something you’re already familiar with.