DEV Community

Cover image for 7 years as a developer - lessons learned

7 years as a developer - lessons learned

Tomasz Łakomy on May 13, 2019

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 b...
Collapse
 
rec profile image
Tom Swirly • Edited

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.

Collapse
 
perigk profile image
Periklis Gkolias • Edited

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.

Collapse
 
ryancosans profile image
Ryan Cosans • Edited

"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 😁

Collapse
 
capaj profile image
Jiri Spac

In a typical corporate environment? For sure, but I certainly know quite a few of programmers who are very successful developing solo.

Collapse
 
mdhornet90 profile image
Chris Murphy

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.

Collapse
 
tlakomy profile image
Tomasz Łakomy

Thank you! I'm glad that we are on a similar path! :)

Collapse
 
apparentlyquiet profile image
Sushant Joshi

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.

Collapse
 
bigpoe_ profile image
Pedro

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 :)

Collapse
 
kylegalbraith profile image
Kyle Galbraith

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.

Collapse
 
omarel profile image
Omar Elbaga

This was exceptional. Thank you for sharing.

Collapse
 
randie_miller profile image
Randie Miller

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.

Collapse
 
kobbyknight profile image
KobbyKnight

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.

Collapse
 
ollytrolly profile image
Oliver Stevenson • Edited

Excellent read! I couldn't agree more with these, I have learnt the same lessons in the past 5 years, often the hard way. Murphy's Law, as you said, often finds a way of teaching you to be more thoughtful in future.

Collapse
 
elmchic profile image
ElmChic

Thank you, Tomasz. I enjoyed reading this and these are useful key transferable skills to develop in any career and helpful in navigating other areas of life (volunteer, social, etc). I just started to learn software development and am looking forward to learning new things as well as utilize my transferable skills in different environments.

Collapse
 
_hs_ profile image
HS

"Your goal is to solve problems with code." - Yup a lot of people miss this point. A lot of people miss the point that they are paid for creating a product not outsmarting each other or check out who wrote the code that made mess.

Collapse
 
timea profile image
Timea Kiss

Oh the dreaded code reviews... One senior dev on a team I belonged to made me feel worthless for 1,5 years. In every.single.review... Holy crap did I try talking to me every few months, did not work, landed on your conclusion... just not a good human being. What is worse though, this sit held me back from growing and learning, made me feel I cannot do anything. I started flying with growth as soon as I quit. Please folks, quit sits like this waaaay earlier than I did. You will do MUCH better. Thanks for the great post. <3

Collapse
 
tlakomy profile image
Tomasz Łakomy

I'm glad you're better now! Thanks for the feedback, I appreciate that :)

Collapse
 
knutaf profile image
knut

Fully on board with all of this, and my favorite one is "learn in public". Showing people that you don't know everything and at the same time showing them the methods you use to learn something is really valuable.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
jpdev profile image
jpdev • Edited

"The problem you solve is more important than the code you write"

Collapse
 
r3i profile image
R3i

" Frankly, I had absolutely no idea what I was doing (this hasn't really changed) "

Lol me too. Also loved:

"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 forget you can test it all you like but then the laptop won't turn on on demo/game day. Have a backup plan for the backup plan.

Great article. :)

Collapse
 
hashimwarren profile image
Hashim Warren

Don’t be afraid to say “I don’t know”

I'm still learning this lesson. I don't want to say I don't know or I need help until I've properly run through trying to build or fix something myself. Unfortunately, that could be 2 days before I realize there's something fundamental I don't understand.

Collapse
 
capaj profile image
Jiri Spac

"Stand up. Reach out to that person in private."

"Learn in public"

So which is it? Okay, if we take the context into account it's not as contradictory as here, but still it could have been emphasized more in the article that the first applies to a specific situation, whereas the second is a general rule.

Collapse
 
katieadamsdev profile image
Katie Adams

"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."
A very bad way to remember that I have not tested this on my project yet... THANK YOU!

Also, this article in general is fantastic. Hopefully you've learned as much from writing it as I have from reading it. Love these little gems of knowledge.

Collapse
 
jan_grz profile image
Jan Grzesik

"Have a deep understanding of what you are building and why"

This paragraph is spot on! I think that engineers and companies hiring them often overlook how important it is to actually understand, and better still, use the product you are building. Especially junior developers, tend to obsess too much with the newest frameworks and paradigms and forget that their job is building value for the end user.

From my experience "product engineers" (as I tend to call them), bring tremendous value to any team.

Collapse
 
melaithepooh profile image
Karmela Deogracias

This article is a gem!

Collapse
 
sadiqur_rahman profile image
Sadiqur Rahman

Great article! Thanks for sharing 👍

Collapse
 
valentinogagliardi profile image
Valentino Gagliardi

Pure gold, thanks for writing this!

Collapse
 
gtcrais profile image
Tomislav Modrić

Love the article, but I do disagree on one point. The first point. What is the most important language in programming? It's English. And English. It's not Spanish, Chinese, or Polish, and it never will be. It's English.
Disclaimer: English is not my native language.

Collapse
 
drissboumlik profile image
Driss

Interesting article, Thanks for sharing

Collapse
 
prameshbajra profile image
Pramesh Bajracharya

This was amazing. Loved it!!

Collapse
 
poulad profile image
Poulad Ashrafpour

Reach out to that person in private. Talk to them, find out why they implemented that code this way.

There is a reason why SO is so beneficial to the Developers. Many people ask questions(newbie, stupid, or smart) on that platform and the good peer reviewed comments from the experts is documented right there. That encourages people to learn in public and share their knowledge.

Similarly, I prefer the discussions to happen in a common place such as a GitHub PR or on the related GH/Jira issue. Team should be encouraged to take a look at them and have an understanding of the reasons behind a specific implementation.

The problem might be the mindset of the team members who think that asking too many questions about an implementation means it's bad code or the implementer isn't skilled enough.

Collapse
 
nathankc profile image
Nathan K. Campbell • Edited

"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"

1 comment or 50 doesn't make you a good or bad person. You can leave one comment that could brand you as the biggest jerk or 50 really useful comments. Tone and working agreements are important. If the "nitpicky" comments are about agreed upon styling standards, design patterns or architecture, then they are legitimate things to point out, not nitpicky Yeah, 50 might be a bit much, perhaps by the 15th comment that could be flag that some screens sharing / pairing could be more valuable, but it's also about preferred working styles. I'd rather have a list of things needing fixed / suggestions written down that I can go back and check rather than keeping everything straight in my head (or trying to write and listen) while on a call or in person

Collapse
 
mardiniii profile image
Sebastian Zapata Mardini

This is fantastic. Thank you so much for sharing.

Collapse
 
molly profile image
Molly Struve (she/her)

Agree wholeheartedly with all of these points!!! I am coming up on my 7 year anniversary of being in this industry as well and I think you hit the nail on the head with this one!

Collapse
 
vjnvisakh profile image
Visakh Vijayan

As my 2.5 years of being a developer in a company that has to deliver product updates/upgrades every two nights ... I have learnt that creating stuff is not as important as creating the right stuff.

Collapse
 
shernz profile image
Shernz

Awesome. Thanks for sharing your experience and knowledge.

Collapse
 
lirantal profile image
Liran Tal

Great post Tomasz! ❤

Collapse
 
faruk_encoded profile image
Faruk Abdulla Munshi

Wow!!! I absolutely love it.

Collapse
 
kyleljohnson profile image
Kyle Johnson

My vote for Dev Quote of the year - "Your goal is to solve problems with code.". Great article. I can see how you have gotten so far in your career in a short time.

Collapse
 
tlakomy profile image
Tomasz Łakomy

Thank you! I'm glad you've enjoyed it!

Collapse
 
nmtoan251998 profile image
Nguyễn Minh Toàn (Noat)

Thanks for sharing. There are so many things that I have to learn from your experience. Appreciate!

Collapse
 
sabderemane profile image
Sarah Abd

Great post! I've learned that we always learn something, at any time in any cases. Even by teaching to someone.✨

Collapse
 
lucioric2000 profile image
lucioric • Edited

That the 'works in my computer' is not valid.

Collapse
 
yemanaung profile image
Ye Man Aung

Support and protect secure system issues for my account and features issues.