Go to main page
A journey into the programming realm
The point of no return
Leaping into the unknown
When you think about what makes someone a good co-worker, or who you should work with, you focus on non-technical skills rather than technical skills.
Below, there’s a list of some soft skills that are interesting to think about, and how they contribute to the project.
For me, each of these skills help with both writing code and being a good coworker, and they are so much more important than knowing a specific language or framework. You should keep growing, so try to make small steps to also improve in soft skills.
Empathy is very important for the quality of the software. By putting yourself in the shoes of the users, you can ask yourself questions such as how the application will be used, or what features would help them or improve their lives.
Empathy is essential for writing good code. If the software is not secure enough, sensitive user data could be exposed to the public. If the software is slow or requires huge bandwith to run, users will leave, and people in areas with slow internet may not be able to run it. The code should be written having the customer in mind, and by satisfying the customer, the product will be of great success.
Empathy is also relevant when you interact with other people. By putting yourself in your manager or another developer’s shoes, you may understand better why they’ve taken some decisions or what you can do to help them.
When interacting with other programmers, especially with the juniors, you need to be patient and trust and believe in their success. Your words and actions have real consequences, and can positively impact a person and change their life with something as simple as a sentence.
Problem solving is the ability to break a problem into smaller ones, that are easier to solve. Getting good at problem solving will help you become a good programmer. Multiple solutions can exist for the same problem, so we also need to think through those solutions and choose the best one. There are factors that influence this decision, such as the time required to implement, the efficiency, or the cost.
As a programmer, you will work with other people. You need to be aware of the fact that many things are contributing to a good collaboration, and many of them directly involve you, such as knowing that one person cannot do everything. Different people have different skills, points of view, and life experiences.
Advices relevant for this skill:
Good communication with other people is crucial, whether those people are co-workers, clients, managers, or people you manage.
Advices relevant for this skill:
First of all, as a programmer, you are the first person that you need to have patience with. Programming is hard and sometimes, you will face difficult problems. If everything is easy, then you are not challenged and therefore, you are not growing as a programmer. You should have the tenacity to keep working through a problem and not give up when it gets hard.
Obviously, you should also be patient with other people too. People do mistakes and failing is a very important experience in the learning process. You should try to create an environment where it is safe to take risks and even fail sometimes, and people will respect you, trust you, and you will all work together to accomplish one goal – creating the software.
Creativity is a great skill, allowing you to think outside the box to create cool things. Having creative ideas is very important for coming up with new features, interfaces, or applications. In addition to that, a lot of problems require creativity to solve. A creative approach to solve problems can also lead to an optimized solution.
You can learn so much from everyone – even from juniors. One person cannot know everything, and you should be receptive to constructive criticism, and learn from it. Feedback is very important for your growth as a person, and you can improve your code or yourself through it. Therefore, you should always be receptive to other people’s ideas, and to always keep in mind that you aren’t always right.
Confidence allows you to face projects, and to solve tasks that you’d otherwise believe impossible to solve. You should not relegate yourself to easier projects or doubt yourself when you are assigned something difficult. In case you’re stuck, you can always ask for help from other people!
You should trust yourself and try a thing or two before searching on google or asking others for help. On the long run, this will make you a better programmer.
In case you have problems building up that confidence, you should keep track of your wins. Keep a document with all the cool things you’ve done, or the good things people have said about you.
In the programming world, you should be able to adapt when things change. You should be able to learn new tools, languages, libraries or frameworks if needed, adapt and evolve. I also strongly recommend everyone to take a day or two and code some small problems in different languages, to see the similiarities and differences between languages, and especially know what each language is good for.
Adaptability is also important when goals or features of the project change.
The community is very big – conferences, blog posts, social media, meetups – all of them are relevant for learning and growing. We also have open source software and the communities that surround them, which are made by the people, for the people.
Curiosity is very important because through it, the developer can grow much faster, and contribute proactively to the team’s overall proficiency. Never stop learning, never settle, and never say never. Challenges are hard, but they are what keep you curious and humble, they motivate you to keep trying and give it your best. You should strive to learn something new every day.
Dunning-Kruger and Imposter Syndromes are two main biases in which people cannot objectively evaluate their actual abilities, either overestimating or underestimating themselves. Both of them refer to the difference between perceived ability and actual ability.
When you start programming, you are sure of yourself. Your problems have only one solution, so that must be the best one. As you increase your technical skills, you find that there are multiple imperfect solutions, and each of them has their own trade offs.
Dunning-Kruger syndrome is usually found in juniors, which overestimate their abilities. As they become better at something, and they keep reading, they realize how little they know. The easiest way out of this is to increase your awareness.
Programming gives juniors a feeling of control, and most of them realise in the end that the problems they solve are much more complex than the techniques they learned so far. Those that do not get to that awareness level are convinced that they know the answer to everything, and not learn another thing for the rest of their careers.
With time, experience, wisdom, learning, and humility, most people get over this syndrome.
The Imposter Syndrome is usually found in technical people, which underestimate their abilities. This happens because, in programming world there is always so much more to learn. We cannot be an expert in every area.
Programmers affected by this, believe that they do not deserve to be programmers, or they just got lucky until today, and people will find out soon that they are a fraud.
But hear me on this: It’s ok not to know about every new tool that just came out, as long as you have a wiling mindset to pick it up and learn it when needed. You CANNOT learn it all. Learn what you need, and when you need it.
Saying that you do not know about some topic is OK. It’s actually great, because you can go and research about it.
If you keep learning new things, trust me – you’re gonna be more than ok.
The comfort zone tricks a person into a false perception of happiness and stability. Basically, it refers to the fact that we tend to do the same thing over and over again – creating a work routine. People are afraid of change, therefore being too scared to make a change and get out of their comfort zone.
If you’re not stepping out of your comfort zone, you will not be challenged, you will not move forward, and you will not grow. In order to get out of the comfort zone, programming wise, you should pick tasks that challenge you, for example:
Learning a new IDE, using a new Operating System, use command line instead of the user interface, learn another programming language, etc.
To get out of your comfort zone, you need to get comfortable with being uncomfortable.
If you are not challenged, you will not get better at something, be it programming, tennis, or anything else, really. If you stay in your comfort zone, you won’t change the way you develop the code.
You need to recognize your weaknesses, and improve on those areas. You also need to know what are your strengths, and build up that confidence. Together, they show who you really are.
The first step is always to identify your weaknesses. Below there’s a small list of programmer weaknesses. See if you identify yourself in any of them, and act on improving them, if so.
Programmers with this weakness takes too long to make any initial progress on the problem, whether this is due to a lack of confidence in problem solving, or simply procrastination.
Programmers with this weakness don’t like to test the code. The code may work for general cases, but not for edge cases. In other cases, it may work but it will not cale up for large problem sets that were not yet tested.
Programmers that are overconfident might write an overengineered code - meaning that the code that they have implemented is much more complicated than it should be, and it could've been smaller and better.
This is a fallthrough case. All programmers are weak in some areas. Some programmers have problems understanding pointers, or recursion, creating and linking classes together, or writing maintainable code.
You need to control your weaknesses. If you skip testing, make testing to be something explicit, and don’t move until you mark it as done. Weaknesses will then no longer be weaknesses, but obstacles that will make you a better programmer.
You must know your strengths, in order to make use of them. If you don’t recognize yourself in any of this, don’t worry – every programmer has strengths. It just means that you either have more to learn enough about yourself, or your strength is something that doesn’t fit into these categories.
Some programmers have a good eye for details. This means that they anticipate edge cases, or they see possible issues before they arise.
Fast learners pick up skills very quick, mainly because they simply enjoy the challenge of learning new things. This also refers to switching to other programming languages, as some people can be productive in another language in a very short time.
Some people are fast coders. They don’t need to use the reference manual to know the required parameters of a given function, and usually they know the project very well, making use of what’s available.
Some people simply don’t give up. When they encounter a bug, they are determined and confident that they will fix it, and they hardly get frustrated.
Some people are great problem solvers. This is mainly because they have lot of experience with the topic at hand, allowing them to make use of prior solutions to similar problems in order to solve new ones.
That’s a tough topic, but I’ll try to answer it as best as I can.
Great programmers are more interested in getting better than any of their peers. Greatness is just as rare in programming as it is in anything in life. In most cases, people don’t want to do what it takes to be at that level. It’s a ton of work and most people don’t dedicate themselves to programming as great programmers do.
Are you ok with being just a common programmer, or do you want more from your professional life?
Do you want to be a common programmer, a good programmer, or a great programmer?
You cannot become great over night.
Ask yourself this:
How long does it takes for someone to learn a new language?
How long does it takes for someone to learn to play the piano?
How long does it takes for someone to learn to paint?
You can learn programming from a book. That doesn’t mean you’ll write good code.
You already know a programming language? Knowing the rules of football doesn’t make you a good football player.
You’ll need to work on your discipline (constant learning), on your attention to details (keep your eyes on the code), on your problem solving skills (keep practicing and keep a positive attitude when facing a problem), on your time management, and on helping your colleagues improve by sharing your knowledge with them.
Whenever you run into a problem, or find the bug you were looking for, try to understand (to really understand) what happened. Podcasts are also a great way of learning, especially when you have to make a long commute, or do a one hour run in the park.
You’ll want to find a mentor, and to surround yourself with smart people. You should always ask questions if you don’t know something. You should ask for negative / critical feedbacks, and to always try to find ways to improve yourself.
You should lower your ego, and be humble - You can always learn something new, even from interns.
Stop comparing yourself with other people and start working hard.
Stop wasting time on social networks or on watching TV when you can do better things with your time.
You go to work for 8 hours – why are you there? If you can’t wait to leave, if you can’t wait for Friday to come, you’re doing it wrong.
Build your work ethic. Change your attitude.
What could you look like in 10-20-30 years, if you give your 100% at work? If you spend any available time on the job, imagine how productive you could be. Probably there’s going to be a lot more code submitted, you’d read a lot of code, learn the code base, come up with ideas or solution to improve it, and so on.
Whatever you do, do it good. Do your best. Give it your 100% every single time. Because the reason is…you cannot become a great programmer if you don’t put up the effort for it.
You will not become great overnight.
The (sad) truth is that, you need to love programming. You need to have passion and to love coding, otherwise I don’t think there’s a chance you can become great. But that’s ok, not everyone has to be great. In fact, statistically speaking, there’s probably 1 or 2 of these in projects of 50 developers.
Everyone wants to be great. 99% of them do not want to put the effort required for that.
You either work hard for it…or you don’t work hard for it.
Some people want to be respected. Others, love the attention (people constantly coming to them and asking them technical questions). Others want to be paid better than everyone else.
On the long term, this will not work. They are not driven by the code. They don’t live code, they don’t breath code.
One day, they’ll give up, because without passion, it’s just a waste of time.
They’ll get bored, they’ll choose and prioritize other activities over this.
They’ll get home and turn on the TV, or play some video games, or scroll some irrelevant webpages – day after day after day - and leave the programming in the corner.
“I code at work, in my free time I relax” – they’ll say.
That’s your cue.
When they relax, you’re coding.
When they watch some non-sense tv show, or some whatever football game, you’ll be learning new things.
When they’ll extend their lunch break with some chit-chat, some coffee, some foosball, and other activities that simply waste time, you’ll be working on the tasks, reading the documentation for some library, read some news about the latest tech, or watch some conference videos.
Of course, you should always make sure you don't burnout, and take some time off to relax when needed, but don't waste time which could be spent coding by doing nonsense.
In the end, remember why you started, and remember why you're doing this.
Passion is what drives you to continue, so keep it up.
As Steve Martin once said – “Persistence is a great substitute for talent”.
Keep coding! Keep learning! Enjoy the process!
Stakeholders: People involved / interested in the topic, that have influence or power over it.
KISS (Keep it simple, stupid), DRY (don’t repeat yourself), YAGNI (you aren’t gonna need it).
Acceptance criteria – conditions that a software must satisfy to be accepted by the user/customer.
Appendix B contain a list of behavior questions.
Appendix C contains a list of questions that the candidate may ask regarding the company.
Will be discussed in detail in Architecture chapter, Quality attributes.
Performance is the ability of the system to execute actions within a certain period of time.
Availability is the ability of the system to be fully or partly operational.
Will be discussed in detail in Architecture chapter, Quality attributes.
Security is the ability of an application to be secure.
Usability refers to how easy it is to use or to learn the application.
Security is the ability of an application to be secure.
Usability refers to how easy it is to use or to learn the application.