Programming is like building a house. Depending on the programmer's knowledge, you will find out in the end if you can live in that house or not.
Programming is a puzzle. We are collecting a lot of small building blocks, learned and experienced during the time. All put together, helping us to convert business needs into IT solutions.
Given a scenario where the same business requirements are provided to 2 developers with significant technical expertise. Each of them will propose a solution that will "work", based on the building blocks they have accumulated over time. Analyzing the result, we will have a general idea about each programmer's experience and what influenced their decisions in the respective solution.
How do people usually learn programming?
There are many options like books, blog posts, video tutorials, team-mates, from trial-and-error experiences and many more. Let's take a brief look at each of these.
Learning from books
Books are a very good learning source. Usually, we have the chance to read the ones which proved valuable over time.
Some of them are hard to read if your level of understanding of the topic is far from the expected one. When you do not understand what the author is talking about, you will probably need to save it for later.
If your experience matches the book's topic, the reading may be interesting. The hardest part is to apply the ideas from the book. So there could be great pieces of advice and explanations, but if you won't apply them, you'll likely forget them sooner or later.
There are also smaller and/or easy to read books, but the question is, how many books have you read during your programming journey?
Blog posts, video tutorials
This approach is usually easier than reading a book.
Blog posts and video tutorials are more likely focused on a single topic. They may share some ideas and experience which are easier to digest and apply.
The same as it is the case for books, if you won't apply the information you're getting out of the blog post or the video tutorial, it's likely that the info will be lost.
Having side-projects, doing small programming experiments, or code KATAs' to apply the things learned by using books, posts, video can make a big difference in your ability to retain the actual information.
Reading and studying are just half of the work; trying, applying, and failing are the rest, for your personal successful growth as well as the one of your team.
Team-mates
The environment and people we are working with have the biggest influence on our personality, way of thinking, and solving issues.
Let's assume that the programmers from the example above worked in teams with different mottos.
Team A’s approach is 'let's do it as quickly as possible', 'if it works, we've reached the goal', 'we don't have time to write automation tests'.
Team B’s approach is 'let's find the best solution for time and quality, 'the solution should work on the long term', 'automation testing done smartly will give the possibility to add new features without affecting existing ones'.
People around us share not just their experience but their mindset as well. The same problem can have multiple solutions and some of them are going to be easily found on the internet. The choice you are going to make will be related to the mindset you've been used to and to the fact you know the actual context.
Ongoing projects
Sometimes, junior developers start their journey and experience on the 'already' legacy projects. This is the easiest way to combine productivity with the high learning curve at the same time. Their experience will be built on the codebase of the respective project and those working on those projects. Unfortunately, the combination of the wrong environment and the lack of experience may lead to some bad habits which will grow and multiply later and eventually also extending to others. For example, you will hear from some experienced people that domain objects should not contain any logic, just plain properties.
Let's break this chain!
Junior developer
As a junior developer, take all proposed solutions with a grain of salt.
Everybody must know all the time 'WHY' we are doing something. In the beginning, it's hard to understand all the concepts like architecture, dependency injection, authentication, authorization, external integrations, you name it. These are configured once and used during the entire lifecycle of the project. That's why more experienced developers tend to say 'it's there, just use it' instead of spending time to explain the real purpose of it. Invest time to get familiar with all the 'fancy' words, it's crucial for your future work on the project. There are important one-time implementation areas that you won't be able to learn if you won't try and fail on your playground or side projects. This way, you will understand 'HOW' the things are built and 'WHEN' they should be applied.
Be patient. This puzzle has many more small blocks than you've imagined. Find the best timing to 'steal' the details from more experienced people. We love to share our experience and knowledge. When you take a coffee break, don't speak about football, movies, or how bad our politicians look these days. Ask about some things you don't understand well enough. I'm pretty sure that the discussions will continue after that as well. Don't make the same mistakes I have, and blindly use some already configured global blocks without fully understanding what sits behind them.
Be curious!
Don't limit your growth with what you are learning on your current project and from your team-mates. Search the people around you that are open to sharing their experiences. Search for alternatives on the Internet and try to understand if things could be done better. So you will know what to use in the future, or even propose an improvement in the current project. Don't be discouraged by reactions like" No, we don't have the time to change this." Just wait for the next opportunity in the respective area, and propose again, and again. Sell it as if it were their idea because many experienced developers don't expect to hear good advice from junior developers.
You know what I mean…
Part of getting results out of a good idea is also onboarding the rest of the team and making them believe in it. It is often not enough just to present it as people have different expertise and different experiences that result in different beliefs and opinions. That makes it paramount to involve the team in the decision and the implementation of the idea.
Don't be a masochist. If you are doing something, and you feel that it's painful, just don't do it. If the application keeps crashing over and over again, if you feel that you are managing spaghetti code or if the team uses wrong solutions, be different. Be the one who will do things differently; take the right approach. And yes, it's very important how you will tell the people around that 'you feel' that you are doing the wrong things. Don't take the approach of the kid who takes his toys and goes home to play alone. Be the kid who keeps asking questions. Why is it crashing all the time? What can we do to improve the current situation? How can we change this? Questions and the respective answers will help you understand what was done wrong. The mindset you will develop will lead your entire career. At the time, you will have more responsibilities, and it's important to be prepared and do things right.
Ask for help. I was a question nightmare at the beginning of my journey in the programming world. People are motivated to share their experiences with those who ask for help. If you are asking, it means you care about the things around you. If there's something that you don't understand from the beginning, no problem, ask it again and ask to get another explanation until it is clear. Not knowing things, it's not a shame. It's a shame to pretend and behave as if you understood’ some may call that cheating. Nobody likes a cheater.
Invest in knowledge. I've met young people with 2-3 years of experience who have better technical knowledge than 5+ years one. The programming world changes very quickly. You should keep the pace, else you'll be 'replaced' by younger, but more up-to-date developers. In the beginning, we are developing our knowledge base, so we are investing time in learning. When we've got some comfort that we can manage to do things, we tend to invest less or even stop learning at all. The comfort won't let you grow, avoid it.
Experienced developers
Encourage juniors to grow. Share from your experience, the good things and the failures. Be honest with yourself, that you've done things wrongly in the past, and are still doing some of them now, that you don't have solutions to all possible problems, that you are still learning every day. That's courage!
Share this with juniors. Share the things you'd do differently if you were a junior again. You've seen a lot of wrong approaches until now, be different. Lead by example, be open to discussing and explaining your solutions for all problems.
Be open. Juniors have brilliant ideas. Yes, they do. Their perspective is different than yours, and it's also fresh. You were 'used to' doing things in a specific way, even if you believe it's the best approach, challenge yourself, listen to others. Be open and analyze other perspectives as well. This will give you the chance to strengthen your ideas or change them to become even better. It's a win-win situation for all parties. Encourage sharing of ideas and try to speak last, so all people have a chance to express their perspectives. It's hard to do that, you have ages of experience, you are the 'expert,' what do young people know… I know this from my own experience, but it is well worth the effort.
Provide feedback. Ask feedback from juniors. This will help them to start feeling comfortable to speak with you, so you can give them feedback later. Show them that you are not perfect, and the only difference between you and them sits with the number of years of experience. Feedback is a must-have tool that should transform into a habit.
Give empowerment. Empowerment generates commitment and motivation. Try an experiment by taking two perspectives. First, give a small task and let the more junior colleague know that failure at the beginning is OK and other defensive pieces of advice. Then take another small task and promote the message that s/he will be responsible for the delivery on time and quality and that s/he can ask for help or validation of the solution. Don't promote babysitting, promote responsibility.
Conclusion
Let's be thankful that we live in a world where we have a choice. Success or failure depends on us. Each of our choices and decisions will influence our future. You will decide to become a programmer or a coder, an architect, or remain an average developer. Regardless of your choice, you will be taken as an example, good or bad. Set your goal, and go for it.
PS I like feedback, positive or constructive. Please share your thoughts with me to help me work on my weakness and strengthen my good parts.