work/career

I read a very interesting article about a study on why some people learn faster than others. It's a very interesting read which I highly recommend, but in case you're short on time I'll summarize the most important parts because they're relevant to the subject I want to cover with this post. The study claims that there are 2 types of mindset when it comes to learning:

• The fixed mindset: People who have this, think that we have a certain amount of intelligence and can't do much to change it. To them, a mistake is a failure, a sign that their capabilities aren't up to the task.
• The growth mindset: People who have this believe that they can get better at almost everything, as long as they can invest the necessary time and energy. They see mistakes as an essential precursor to knowledge, the engine of education.

Needless to say, people with a growth mindset turned out to be significantly better at learning from their mistakes. The article also covers a very interesting experiment involving school children. The children were given a test, and half of them were told "You must be smart at this". The other half was told "You must have worked really hard". After that, they could choose between 2 new tests. The first one was more difficult, but came with a mention that the students would learn a lot from them. The other test was similar to the test they had just taken.

And here's where it gets really interesting: of the kids that were praised for their effort instead of their intelligence (I'm going to refer to this group as the effort-kids from now on), 90% of them chose the harder test. Of the kids that were praised for their intelligence (I'm going to refer to this group as the intelligence-kids from now on), the majority chose the test that was similar to the one they had just taken. Presumably, to avoid risking a low score after having already been praised for their intelligence. After the second test, all of the kids took the same third test, which was the hardest one so far. The effort-kids worked hard at figuring out the puzzles, while the intelligence-kids were easily discouraged by their mistakes. After the third test, the kids were given the choice to look at the exams of kids that did better than them, or the exams of kids that did worse. The effort-kids generally wanted to look at the exams of the people who did better. The intelligence-kids mostly picked the exams of those who did worse. The final test had the same difficulty level as the initial test. The effort-kids raised their average score by 30%, whereas the intelligence-kids saw their average score drop by 20%.

I find that kinda stuff fascinating. It also kinda confirms what I've seen from fellow developers ever since I graduated and started working. Every good developer I've met isn't afraid to make mistakes and sees mistakes as learning opportunities. These people routinely challenge themselves by learning something new. They also keep an eye on what other people are doing to get better and they actively try to learn from people they consider to be better than them.

One guy I used to work with was considered to be a great developer a few years ago. Now this was the kind of guy who was not only used to being praised for his 'intelligence', but his self-confidence was largely based on it. He once told me his favorite class in high-school was math because the other people in his class thought it was hard, while it was easy for him. He actually said it like that. When other people started getting more attention for their technical skills and knowledge, he began to move away from coding and started focusing more on writing functional analysis documents. He wasn't bad at it, but it wasn't great either. Now he does a little bit of everything from what I've heard. I'm pretty sure that if his self-confidence wasn't based on the praise he gets, he could've been much better at whatever he wanted to do.

That's just one story but I've seen similar things with other people who seemed to be more interested in what other people thought of what they could do as opposed to actually trying to improve on what they can do on a continuous basis. If they start thinking rather highly of themselves because of the praise they get, they often start thinking it's just not necessary anymore to keep working on improving their skills.

Keep challenging yourself. If you think you're pretty good at what you do (and there's nothing wrong with that), make sure you keep searching for new and better ways to do what you do. And when people praise you for being good at what you do, don't let it get to your head because before you know it, you won't be getting much praise at all anymore.

Nobody likes to maintain a bad codebase. And still, it's an experience that i'd recommend to every developer, particularly early on in your career. People who are relatively new to coding usually don't have a good view yet on what kind of code will cause pain in the long run, and what kind of code won't. And if you keep getting assigned to new projects, you're less likely to develop that view properly compared to someone who has to maintain an existing, problematic codebase.

We've all heard the most common ways of improving as a developer: read the right books, learn from more experienced people, and above all: practice, practice, practice! And all of that is indeed very important. But i've always felt that being exposed to bad code and having to deal with it can be a tremendously important and valuable learning experience as well. As valuable as repeated practice, reading and following advice from experienced and skilled developers is, none of it will stick with you as long as the pain you feel day in, day out from working with a bad codebase.

When you're working with a bad codebase, it's important to figure out where the pain comes from. Whenever you experience pain while trying to make a change, or while trying to implement a new feature, take a bit of extra time to look for the cause of the pain. Then try to think of a way that would avoid the pain entirely, or at least lessen it. And if you can, implement your solution in the codebase. If you can't, try the approach you thought of in a personal project. If you do this routinely, you're going to learn a lot about what works well and what doesn't. I'd dare say that you'll get a better view on this than people who never have to work with legacy code, since they rarely get exposed to the long term problems caused by the code they write.