Before we start - I'm working on https://cloudash.dev, a brand new way of monitoring serverless apps 🚀. Check it our if you're tired of switching between 50 CloudWatch tabs when debugging a production incident.
Time flies, doesn't it?
My programming journey began in 2012, with my very first C++ internship. Frankly, I had absolutely no idea what I was doing (this hasn't really changed). Nevertheless, I've picked up some lessons along the way.
Disclaimer: There isn't going to be any code whatsoever in this post.
Question: What is the most important language in programming?
It's English.
Or Spanish.
Or Chinese.
Or Polish.
Or whatever you use to communicate with other people at work.
Talking to humans is way more important than talking to machines
Programming is a team sport. On rare occasions you might see a brilliant product built from scratch by a single person but in the vast majority of cases - you need a team.
Communication skills can make or break a project. Don't worry, it's not just you and your team, NASA is struggling with that as well.
Soft Professional skills can be more important to a project success than purely technical ones. Who cares if you hire 5 of the best database experts in the world if they refuse to talk to each other and you end up with 5 different instances of MySQL, Aurora and MongoDB.
Have a deep understanding of what you are building and why
Most people are happier when they have a sense of purpose. This applies to work as well.
As a software developer your goal is not to translate JIRA to JavaScript, Trello to C# etc.
Your goal is to solve problems with code.
If you have a deep understanding of the system you're building/maintaining then you can make decisions outside of pure tech. Is this feature even necessary? What problem does it solve? Can we solve this problem any other way? Do we want to solve this problem in the first place?
This line of thinking is sometimes referred to as business context, but if you want to do your job well, you should not only understand the context, but to be able to shape and influence that. You don't have to have a C-level position in your organisation to influence your product. Or at least - to understand it.
If code review in your team is a stressful experience you are doing it terribly, terribly wrong
Oh boy. Code review.
We really don't think about it but the act of putting our work out there in public and have it reviewed by multiple other people is a bit unique to our profession. No wonder people can be anxious about the whole experience.
I have personally seen people submitting code reviews when X wasn't in the office, or Y was at a business trip. X was a brilliant programmer but enduring through his code review process was a chore. If you leave 50 nitpicky (is that a word?), unkind comments under a PR of someone who is a junior programmer, you are not proving your superiority as a developer. You are proving that you're not a good human being.
Okay, but what do I do when I see that this feature is completely broken?
Stand up. Reach out to that person in private. Talk to them, find out why they implemented that code this way.
Most people do not want to write bad code. And if they do, they probably are dealing with constraints you're not aware of. They could also not be really good at programming (yet) and it's your opportunity to shine as a mentor.
Something WILL go wrong, be prepared
According to wikipedia:
Murphy's law is an adage or epigram that is typically stated as: "Anything that can go wrong will go wrong".
It's one of those things that are too true. Always assume that something may break when designing a system.
If you're building a login form, assume that people will copy&paste an entire book into the password field.
If you're building a WYSIWYG window, assume that someone will try to break it, and they are likely to succeed.
If you have a database, it will go down at some point. If you haven't tested recovering your database from a backup, it's not a backup.
If you're doing a live demo in front of an audience - make sure that the demo works online, offline, upside down and under water.
Don’t be afraid to say “I don’t know”
The best part of having a senior next to my job title is that I can finally respond to a question saying:
I don't know, never tried that. I'll take a look and I'll get back to you.
When I was a junior, I was terrified of someone figuring out that I'm a fraud. After a couple of years as a developer - if I haven't seen something, it could be that it wasn't relevant till now. Or I just have another cool piece of tech to learn. Lifelong learning is not a buzzphrase in software development, it's the reality.
Or I'm just an incredible fraudster, managing to fool all those people that I can actually do my job. You never know.
Learn in public
Once you go from "I don't know" to "Okay, that was interesting" - share that with someone. Write a blogpost, record a video, do a talk at a company knowledge sharing event or just ... tell someone. If you think that something is obvious to everyone, it's not. Even the most senior people have something to learn from beginners and vice versa.
Teaching is an incredible way of ensuring that you really understand the subject in question.
As the saying goes:
When one teaches, two learn - someone hella smart
What are your lessons learned as a developer?
Top comments (45)
I loved the article and agree with almost all of it, particularly the "things go wrong". I feel that you need to switch over periodically and become your own enemy and try to think of obnoxious things that could conceivably happen. I remember we had a QA guy named Dan Song - an ace. Once he bet us he could immediately break this program we were working on - one he hadn't even seen - and we said, "Sure". He walks over, we bring up the program, he hammers on the keyboard incredibly fast, it crashed instantly. The other programmers were all, "That's not fair!" but I had a revelation.
And Dan had a lot of tricks other than that. I realized that before then I had been testing code to try to show it working - now I started testing my code to try to make it break. Changed my life!
The one thing I disagree is the "50 comments on a junior developer's first review makes you a bad person". I disagree - it's doing this out of the blue, with hostility that makes you bad.
I started in a new organization with 20 years' experience under my belt and the first five code reviews were relentless with huge numbers of comments! But all the comments were warm and friendly, and I had been warned in advance that it took a long time to get all the details right in this huge system. People were supportive and told me that I was doing a good job. I was told to expect perhaps hundreds of comments on my first significant code review, so when there were only about 50, I felt I was doing OK.
Reviewing code in private is wrong - because you want to share the information with the team. I learn more from reading other people's code reviews than perhaps anything else. I ask myself, "Why did they do this weird thing?" and then I read the code review and I say, "Because it's the only way that will work!"
Any number of comments on a code review are fine - if the reviewee is primed to expect this before anything happens, and if the comments are supportive and positive.
Great article though - this is just a quibble.
Great article. As a non-native English speaker, I would also add that the most important language is:
English AND whatever language you use to communicate with other people at work.Whether we like it or not, the vast majority of the learning material is in English. So, no English, no learning, no party.
"Programming is a team sport." I've been saying this exact thing for years. Thanks for sharing your experience it was a really good read 😁
In a typical corporate environment? For sure, but I certainly know quite a few of programmers who are very successful developing solo.
I'm gonna go ahead and pile on with another "great article" comment. I've been devving for just about the same amount of time as you and your journey absolutely reflects mine.
I am definitely one of those devs that's very particular about how "clean" the code is, but I try to never make assumptions about why someone went about solving something a particular way - I always ask first for exactly the reasons you said, and often times I do end up getting a very reasonable answer. I think it's ok to be somewhat nitpicky as long as your intentions are to make sure the codebase is more maintainable and consistent for everyone, not just to satisfy one's own ego.
Overall, something that took a while for me to understand is that technical proficiency is NOT a career goal, it is merely one facet among many of being a well-rounded engineer. People ultimately respect a combination of being able to solve problems, being able to communicate your approach, being able to admit when you don't know something or when you made a bad call, and being willing to trust your teammates and work together with them to make the best code/product possible.
Thank you! I'm glad that we are on a similar path! :)
This was a really great article! Thank you for sharing your learnings Tomasz!
I really liked that you focussed not on code or technical factors, but rather on the human aspect of working as a software engineer.
Having said that, I'd love to read another part of this story where you write about your learnings from a technical point of view. Things like how has your attitude towards problem solving, coding choices, etc. changed over time. Or any other learnings, in fact :)
I'm sure the community would benefit a lot from reading about your journey and learnings.
Thanks for the read!
Completely agree about is more important communication skills than technical skills. We need to learn how to communicate our ideas and thoughts effectively with different people to resolve the problem we (as a team) are facing.
And yes, when is your turn to teach something is when you realize if you really understand the subject or not.
Cheers :)
Fantastic article Tomasz, you really hit a few points that I think are critical for everyone to know. My favorite is "Have a deep understanding of what you are building and why". So many folks enter this industry thinking that it's all about cranking out code for 8-10 hours a day.
It's really not. It's about building just the right things with just the right amount of code to make the lives of your users easier. It's not about the tech, the language, how much code you write, etc. It's about answering the question, does this solve the user's problem? Sometimes, solving that problem doesn't even require any code.
This was exceptional. Thank you for sharing.
Great article, concise and hitting the points that really make a difference. I would stress that the first step in communication is to listen, observe and learn. Things work much smoother if developers can learn the business and then see how technology can improve the process.
I think we tend to get wrapped up too much in technology and think of systems as their implemented tech and not the problems they solve. We talk of a system with a React frontend, backed by Node microservices with MySQL persistence, not as sales prospect process that is needed to keep the revenue flowing to sustain the business.
Some of the best systems that I "developed" were one's that I never wrote. Often what is needed is a function that is already present, just not done where or how it was expected. Changing expectations or slight modifications to meet expectations are what's needed, not more code.
I can't agree more. Certainly admitting not knowing more and being open to ideas from others is an effective way of being a better developer.
Also, I've had the chance to mentor a few other programmer although I don't consider myself a senior dev because there's so much I have to learn. In helping others fix code I've found out that trying to get the reasons why he/she chose a particular approach makes me pick up some lessons from them. It also ensures they feel good about themselves as their opinion or approach is being considered.