Hi! Our names are Adrien, Benjamin, Fabien, Florent, Johan, Laurent and Rainer. We have been working in the software industry for several years. We share a growth mindset and always enjoy taking a step back to retrospect on what we've learned.
During SoCraTes France 2022, we decided to put together a few words of advice to our younger selves. Tips we wish we were given when we started in the profession. We hope that they will be helpful to newcomers of our industry.
Write Tests
Writing code that does what we intend is hard. So we regularly test these intended behaviors. As code evolves, new bugs will appear, and old bugs may re-appear. Writing automated tests helps us find bugs before they impact the users of our software.
Automated tests give us trust in our code, and a feeling of safety when we change that code. Seeing automated tests pass is addictively satisfying. Automated tests make our lives better. We love getting continuously better at writing them.
Working on legacy code convinces us of the importance of automated tests. They help us understand and improve code for the long run, and reduce the risk of causing bugs while doing so.
Test-driven development (TDD) helps us develop our skills, by encouraging us to write higher quality code.
Code With Your Teammates
Code is rarely meant to be read and changed by just one person. We write code that our current and future colleagues can understand easily.
Preferences are personal. There is no winner in the "tabs versus spaces" debate. Using both makes a codebase look bad. Consistency makes code look the most clean and professional.
We discuss preferences with the team. Agree on common guidelines, then stick to them. If your preference is not agreed upon, remind yourself that this is not about you. Also, remind yourself that your preferences will evolve.
When we feel stuck by a technical problem, it's most likely a people problem. We don't jump to conclusions. We don't jump to solutions. We explain our problem to the team, ask for their help, then find a solution together.
Pair programming is not a waste of time. It helps find better solutions to problems, faster. Pair programming is an opportunity to learn and grow. It makes us converge to design decisions, instead of having to defend our choices after implementing them.
Ensemble programming (a.k.a. mob programming) is pair programming at scale. With more brains involved, we find more adequate solutions. By programming all together regularly, we won't have to document or repeat ourselves as much.
Learn, Chat, Share
Loving to code motivates us to practice and learn. Building software with a team helps us have a bigger impact. Confronting our ideas, opinions and experiences to other developers helps us develop our craft.
At local "meetup" communities, conferences and un-conferences (like SoCraTes), we learn about new practices. We share our experiences. We make new friends. These discoveries help us orient and improve our career. Friends sometimes become team-mates.
We learn about the history of computer science to better understand why things are the way they are. We learn about fundamentals to avoid reinventing the wheel. We discuss principles and methodologies to feel wherever and whenever it's appropriate to not follow them. We play with different languages to discover new mental models that may become handy someday.
We ask our peers to recommend good books to read. We form skills and opinions by practicing what we discover. We help other developers grow by sharing our learnings with them. It's never too early to start sharing. And there are various ways to do so.
Improve the Collaboration Progressively
Building software is not a sprint, it's a marathon. Our goal as developers is to solve problems by writing code. After some time, that code may become the source of new problems. We are mindful of the consequences of our choices. We inform our colleagues of the implied costs and risks, so we can adjust the strategy if necessary.
Deadlines are artificial. If we feel we can deliver a requested feature on time, we go for it. Otherwise, we negociate the deadline. Or propose alternatives. Understanding the objective or constraints behind a deadline usually helps.
We collaborate well with our squad. Contemplate how features are brought to life, from ideation to production. Understand how our contribution fits in the production cycle. Get to know our collaborators, stakeholders and the users of our software.
Whenever something is missing to do our part well, we ask. Whenever we are not sure to understand what is being built, for whom, or why, we ask. Whenever we are not sure about something, we are not afraid to say "I don't know".
We are not afraid to fail. Retrospectively talk about failure (without blaming) is how we learn and improve. We just strive to not commit the same mistake twice.
When leading a team, it can be tempting to point out several problems about the codebase, the processes and/or the team that made it. Bringing change is difficult and takes time. We don't change too many things at the same time. Instead, we start with the most critical or impactful change, then proceed with the next. We pick our battles.
Design Slowly
Software grows quickly. While growing, its complexity also grows. We strive to keep complexity to a minimum, by properly understanding and modeling the domain of application of the software. Domain-Driven Design (DDD) is one way to remain connected to users and stakeholders, and to keep the corresponding complexity in check.
We don't let technical details impact the domain logic. We design our code in a way to make it easy to replace external dependencies: databases, caches and 3rd-party APIs, without impact on our domain logic.
Performance is not always a priority. Unless needed otherwise, we prefer code legibility and separation of concerns. We design services that can scale independently rather than optimize code prematurely.
When we are considering a solution to a problem, we discuss its pros and cons. We keep a trace of our decisions in Architecture Decision Records, to help our future colleagues understand what compromises we agreed to make, and why.
You Are In Control
We are not servants to our employers, clients or managers. We negociate each job or mission opportunity towards a win-win partnership. Salary is just one among many variables to discuss. There are many others: opportunities to learn, to discover an interesting business domain, to try out a new role, to work with exceptional colleagues, to find the right work-balance, etc...
Sleep is not a luxury. Our job requires a healthy brain. To be productive and creative, our brain needs a lot of time to rest.
Health is not a commodity. We take care of our physical and mental health. If work ever compromises it, we seek medical assistance and take measures to resolve the situation as soon as possible. No job is worth sacrificing our health, sanity or dignity.
When a colleague seems to loose control, we propose assistance. We don't tolerate harrassment or abuse of any kind. We stand together against it.
That's all, folks!
Take great care of yourself, and of your community. Take the time to figure out what you love doing most, and why. Be proud to stand by your values. Strive to bring and sustain a positive impact for your collaborators, stakeholders, users, without ever compromising on quality, honesty and humility.
Authors:
- Laurent Bossavit, Technical Advisor at CodeWorks
- Fabien Giannesini, Software Crafter at SHODO
- Benjamin Hugot, Software Crafter at SHODO
- Adrien Joly, Software Crafter at SHODO
- Johan Martinsson, Tech Coach
- Florent Pellet, Software Crafter
- Rainer Standke, DevOps Engineer at DB Systel
Top comments (0)