What the best teamleader Ján Regeš taught me

Ján Regeš, a colleague, friend and especially a great person, has been working at SiteOne digital agency for over 15 years. He was my first teamleader when I started programming. I remember our cooperation very fondly, because he always managed to pass on a lot of useful know-how that I wrote down and only understood years later.

I managed to interview Janek some time ago, and ask him in retrospect how he perceives working with juniors, and how to do things really right. I have long since understood the difference between what I thought years ago and how I perceive things today. It's all about collaboration, humility (towards people, towards technology, towards companies), ... in short, Janek wrote it beautifully.

Here are his insights:

• You're young, intelligent and very skilled, but imho too confident, both in programming and business - you've undoubtedly taken a big step forward in knowledge, but you need to explore further.
• Accept your current knowledge, knowledge and even possible contacts with humility and give yourself a few more years to consciously explore the world (technology, business, personalities...). You won't miss any trains. When you need to make bigger and harder decisions, you'll have more data, experience and more refined instincts for them.
• Get a handle on which of your skills or technologies you are most proficient in, or want to develop the most, and choose your next employer accordingly.
• Don't go for the money, but for the good feeling of a job done, a team enriched, value delivered or a need met. It's a cliché, but money will go hand in hand with it if you focus on the right thing of your professionalism.
• If you start somewhere, map and understand who your work environment delivers to and what your "quality" and "value" is actually perceived by those who commission and pay for the project. Learn to focus and deliver high quality and value, not just "good code". There are companies and projects where your delivery is about a small piece of code that has to be perfect, rigorously tested and known to run for the next 10-15 years. But there are projects that will run 2-3-4 years, and where the expected quality and value is completely different than the programmer thinks. Learn to perceive this, differentiate, and if necessary ask questions like this of your co-workers or the client.
• Admit to yourself that every few years, if you look at your code from 2-3 years ago, it will always be no-good, even if you felt it was state-of-the-art before. It's better and more promising to focus on the resulting quality as perceived by the "client" - be it internal or external. Those are the most positive things that will remain and recharge you and the associates or clients you've worked with in the past in the future.
• Give your heart to your new environment - understand where their "problem" is, what will help them the most from your distinctive skills, communicate that with your supervisor, and do it with a quality outcome in mind, not quality code. Maybe the environment needs your strengths other than programming.
• Help, but always with humility - respect and try to understand the perspectives and opinions of others who have real responsibility and are prepared to bear the successes and risks of their decisions for years to come. In the context of a programmer, this includes technology decisions, stack selection, or direction and longer-term strategy.
• As a programmer, always submit rigorously tested work. Read every line of your code in the diff before every commit. Test the prepared UI interface on X different scenarios and try to play a lot of simple but sophisticated user in yourself. Don't rely on testers or extraneous CR - this is just a good supporting bonus when the team has these processes working.
• Keep the KISS rule in mind and watch out for over-engineering. If you do things simply but efficiently, flawlessly, safely and with clear boundaries, it's better than inventing a nuclear super-modular power plant and architecture. It depends on what you're doing, but imho in most cases it's better to choose the simpler solution.
• Whether you made good architectural decisions will always become apparent after years of operation and implementation of future functionality. Unfortunately, the reality is rather that most of today's programmers change jobs rather quickly and have no idea what the positive or negative impacts of their earlier decisions are and therefore whether they were good or bad.
• Learn to recognize and work with reasonable and fair people who are not just about business, but also about the real value of what they do and for whom they do it.
• Live and work in such a way that when someone in your family asks you what you're working on, your answer is honest and more about helping your clients meet their needs or dreams in the world of the internet, but not about being a perfect programmer and writing perfect code. There is no such thing as perfect code, but the only testament that you had good code is when years later the owner or collaborator of one of your projects/products compliments you that it was good to work with all the time, or that it expanded nicely.
• Don't let it get you down and think about your physical and mental health. Work only 8-10 hours a day. If you choose to spend some time on the PC after hours or on weekends, you shouldn't call it work you "had" to do. Make sure you tell yourself in hindsight that it was a great decision. I myself give a huge amount of time to work, but that's only because the things I do after hours don't stress me out, make me happy, improve the professional climate for our team or myself, and even after many years I don't regret the time I invested in it. I only do as much as I want to do and as much as my family allows me to do. I feel free and I know. Even though I've been doing it for over 16 years.
• I wrote the previous point mainly because it's clear to me that you give it about as much time as I do, but in retrospect often evaluate that it wasn't the best use of your time (typically working for the wrong people or projects). Be careful and choose your collaborations consciously and with clearly agreed terms.
• Know, perceive and fulfill your life's mission. Even if you experience difficult times in fulfilling it, at least you won't doubt whether you're on the right path, but you'll focus on overcoming obstacles along the way instead of ruminating over nonsense.

Jan Barášek   Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu:

Kontakt