Professionalism

From web to mobile development

Julien Fiaffé General , ,

desktop-mobileI started my developer career as a web developer, using PHP. Soon after I switched to the .NET ecosystem to continue web development using C# and the ASP .NET MVC framework. I was creating web applications for my entire professional life until recently.

A few months ago I started working on mobile applications for Android and iOS, yet still with C# thanks to Xamarin. I am creating this blog post to share how I feel after this change.

Why this choice

You might wonder why I decided to switch from web development to mobile development. Because I wanted to work on something new in order to learn new skills, even if I still have a lot to learn regarding web programming.

I also think that mobile applications still have a bright future, sure there are already a lot of them on the existing stores. But new mobile devices are coming, like the smart-watches, and they will provide new opportunities for the developers. It is a good time, in my opinion, to learn how to create applications for mobile devices.

At my current company there was an opportunity to work on the new Android and iOS applications using my favorite language (C#) so why not take this chance.

A new paradigm

I knew that the way of programming would change since I already experienced mobile applications development with a project on Windows Phone. But still I was not prepared for what I have to do and I don’t think I could have been prepared.

Unlike a website an application has a very specific life cycle, you don’t just answer a request with a response. Almost everything I learned building web applications does not help me, the paradigm is entirely new.

Asynchronous programming is mandatory in this world, if everything runs on the User Interface (UI) thread the application will freeze. I always wanted to improve my skills in this area, looks like I found a good opportunity for this goal.

The separation of concern is also different, no more Model View Controller (MVC), now it is time to use the Model View ViewModel (MVVM) pattern. Even if I already used it (WPF and Windows Phone), it was not at the same level and I still have a lot to learn.

And of course you have the emulators to test the application, each time you want to test you have to build and deploy it, you cannot just refresh the page to see the changes. The feedback loop is long, several minutes most of the time, therefore debugging feels slow and debugging is important when starting with this technology.

Outside the comfort zone

I started working on the applications about two months ago and I still have a lot to learn. I need to deal with two ecosystems I know nothing about (Android and iOS), two frameworks I know nothing about (Xamarin and MvvmCross) and the business requirements which are not the easiest to meet. But at least I know how to use C#.

At the moment I struggle everyday, I have a lot to take into consideration, mostly some “How?” questions related to my new development environment. and also a lot of “What if?”: “What if the network is not available?”, “What if this solution is too slow?”, “How to provide the best experience for our clients?”…

Sometimes I cannot manage to produce anything for an entire day, and to be honest I feel worthless, I feel like I am a fraud… How can I consider myself has a professional software developer if I am not able to produce anything of value with my work?

Well, I guess this how it feels to step outside my comfort zone and I think I am in a ravine of the learning phase.

Learning Rate With Ravines
Learning Rate With Ravines

I will not give up

The thing is, that I am not the only one in this situation, I am not the only one to struggle. In the team we all have to deal with the same amount of learning, senior developers and junior ones.

When I take a look at the journey I began two months ago I realize that the route is still long but I also learned a lot, I am more familiar with the concepts of asynchronous programming and those of the MVVM pattern.

If I want to consider myself as a professional I will complete my journey and I will learn the skills I lack in order to produce the value our clients expect. Even if my work is painful from time to time, I have no regret, this is a massive opportunity to learn. I will succeed no matter how much time I need. And I hope to be able to share some Xamarin tips and tricks on this blog in the future.

See you next time!

Software gardening

Julien Fiaffé Principles , ,

Butchart-Gardens-CanadaA few months ago I discovered a new manifesto related to software development: the Software Gardening Manifesto. Even if the manifesto has been initiated in 2015 (by Papapetrou Patroklos), the concept of software gardening exists for several years, Jeff Atwood wrote about this topic seven years ago.

If you work in software development like I do, you certainly know the struggle when it comes to explain your work to non-technical persons. Using the metaphor of a garden can be a helpful metaphor. But software gardening is not only that, it is also values and principles. I like what I read in this manifesto and this is why I am creating this blog post.

Deep dive into the manifesto

So, what is the definition of a software gardener when we take a look at the manifesto?

Software Gardeners are professionals who perceive software development in a different way. Our goal is to spread the word of our core values, be mentors for the new developers and create software that it is developed at the highest quality bar.

As someone who values the principles of the software craftsmanship movement, I share this definition since it looks similar as the definition of a software craftsman.

To find the analogy with a garden, let’s have a look at the “beliefs” present in the manifesto.

We treat software systems as gardens and code as flowers. Although we don’t disagree regarding software as a “craft”, we believe that software is a living and breathing “being”, not just an object, created using the best materials.

The fact that systems and code are considered as living entities implies that they need attention over time. Your code gets updated to add feature or to fix bugs, the system changes over time to be improved, refactoring phases occur. It is likely that the project you work on is updated everyday even if it is already in production, of course depending on the context, some features are removed to make room for new ones.

We constantly mentor young developers and we share our knowledge at every opportunity. Junior developers are like flowers that need to be irrigated to blossom. We are the water, the sun, the soil, the fertilizer for every (young) software professional.

Software gardening is not only about taking care of the code but also a community where the more experienced developers help the younger ones by sharing their knowledge and skills (water, sun, soil and fertilizer). It is about creating a community which is a value shared also by the software craftsmanship manifesto.

Software development is a lot more than slinging code. We know the practices and we apply them effectively. We make use of the most productive tools and our skill-set includes both soft and technical skills. We also understand that our overall attitude is what defines us as software gardeners.

Creating software and growing a garden both require tools and skills. And it is definitely better to have the right tools for the job and knowing how to use them effectively. Having values is also important in order to provide the best work as possible.

We care about our code and this care, we show it continuously, day by day, every moment in every single line of code we write.

Code is like a flower, it is delicate and needs proper attention in order to flourish. A mistake can have painful repercussions later, do not water your plants and they will die, do not refactor your code when needed and you will have to deal with technical debt.

We are not only able to respond to change but we are prepared about the endless – internal and external – environment reform.

I find this one very interesting because of the notion of “environment”. Growing a garden does not always require the same tools and techniques, it depends on the context. Is your garden in a forest, a plain, a jungle or maybe a desert? You definitely need to adapt to the constraints of the environment you work in. And it is the same for a software project, do you work for a small company or a big one? Is there a lot of processes or not at all? Is your team made of 4 developers or 20? Is the project new or an old legacy system from 10 years ago.

You need to adapt to all of these variables and they might change over time, nothing is finite, everything evolves, remember that: “The only constant in this world is change”.

We treat customers as the people who will walk in our garden and smell our fragrant flowers. Having said that we engage them from the first day, to make sure that all their needs, requirements and expectations will be met.

Collaboration is essential for a software gardener, working closely with the customers is mandatory in order to create the best possible result. Understanding them is important to be able to have a beautiful garden years after years, during all seasons.

Conclusion

Software gardening is about commitment, quality, pride and love for the code and systems we work on. In ways it is similar to the software craftsmanship with an emphasis on the “living” part of the code and the analogy of the garden environment with the software environment.

Remember also that it is just a manifesto so you have to read between the lines in order to fully understand the values and principles behind this approach.

To me it is refreshing to see a new metaphor for our profession/passion/craft/art that is not related to classical engineering work. Which is, in my opinion, not always a good comparison for software development. I recommend you to read Chris Aitchison‘s article on software gardener: You are NOT a Software Engineer!

See you next time!

Image credits:

http://positivegardening.com/top-10-most-beautiful-gardens-around-the-world/

Testing is a developer job

Julien Fiaffé Software craftsmanship , , ,

lack-of-testingMaybe you have heard about the various discussions about Test-Driven Development (TDD). Is it worth it? Does it lead to good design? … In this blog post I will not speak about this kind of practice, just “classical” tests.

When I started my software developer career, I knew nothing about automated testing (unit or not). I wish I did, it would have save me a lot of time and a lot of trouble back then.

The pain of legacy code

I started my life as a software developer in a small company, I had no experience and I was alone on the project, which was several years old. I had to deal with a “big ball of mud” where I was afraid of touching anything because I did not knew anything about the consequences it might have.

Yet, I had to fix bugs and to implement new functionalities in order to improve the application. Of course, I did not test much my changes, only that the bug is fixed or the new feature works as expected on my local machine. And every time it had unseen consequences because the code is highly coupled and changing one part of the source code change the behavior elsewhere.

I wish I had tests at that time to prevent me from working in fear, fear of breaking things, fear of regression. But I’m also guilty in this story because the number of tests I have added during this period is ZERO… My contribution was to make the whole thing worse by adding more legacy code.

I now realise that I was behaving un-professionally, legacy system is a real pain to work with and it is my job as a software developer to avoid creating this kind of mess. We have the tool and practices to make things better, we can add tests, we can refactor bad written code.

Whatever… QA will test it

Now I work for a larger company with several development teams, each one of them has a QA to validate the work done by the developers. I think that having QAs within the teams is a wonderful thing, they will check new feature and potential regression before a production release.

But sometimes I feel like that some developers see this situation as an excuse to be lazy. “I just code, I won’t test it, this is the job of the QA”. What?! Are you serious? Your code does not even compile! Sure the QA will test it and they will just say: “It doesn’t work”. They can’t even test a single feature because the entire system cannot be built.

This might look far-fetched but I’ve seen situations like this one, several times unfortunately.

Sometimes, the code “works” but what has been asked is not done, the code has been written and it compiles. Yet, when opening the page (example of a website), the new element is not present… It’s the developer job to open the site to make sure that it works as expected from end to end, at least locally. Again, I’ve seen it many times, with my own work as well.

In my opinion, QA should find nothing, if they do I have failed at some point. If the issue is technical, I made a fault and I need to fix it ASAP and learn from it. What do I’ve missed? How to prevent that from happening again? Is there a unit test I can write? If the problem is a business issue (not doing was it is supposed to do), then again: what did I missed? Is there an acceptance test that needs to be written? Did I know all the domain related details? If not, why?

Always learn from your mistakes and a feature not validated by QA is a mistake. QAs are not hired to piss developers off, they are paid to make sure the products are viable from a quality point of view. We are not paid to write code, we are paid to automate process, and make them work! QAs are here to help, not to do our job.

I’ve been down this road and this is why I make this blog post, to share my experience and my failures. I love my job as a software developer and I want to be proud of what I’m creating, I want to be considered as a real software professional. There are ways to improve how we work, from a technical point of view and an attitude point of view.

Testing is a developer job, unit testing, integration testing, manual testing, all of them. It’s our job to make sure everything works.

See you next time!

Image credits:

http://www.mobilisationlab.org/six-testing-ideas-for-your-next-email-campaign/

Extreme Programming: Continuous Integration

Julien Fiaffé Development Practices , , ,

red-green-refactor-commitAs professional developers, we want to get feedback as soon as possible in order to detect any potential issues in our software. To do so we can practice Test Driven Development (TDD) to make sure that our code is fully tested. We also have a full acceptance tests suit that prevent us to have any regression regarding existing features.

Yet this might not be enough to ensure the quality of the software we build. It is likely that you work in a team with more than one pair of programmers.

Conflicts and merges

Now imagine that two pairs work on different user stories, each duo practice TDD to ensure the quality of their developments. After a day or two both teams are done, all tests are green and the acceptance tests still passed, time to commit/check-in the code to the source control.

But unfortunately both pairs updated a common part of the project, the first team will commit their changes without any issue. But the second team will have to deal with a lot of conflicts and merges before being able to save their work on the source control.

Maybe you haven’t experienced situations like this one before but if you do, you probably know the pain it can be to merge a project full of conflicts, it can take hours…

Avoid Big-Bang commit

Conflicts and manual merges occurred, there is always a time when several developers work on the same part of a project. But it is possible to ease this process in order to avoid such situation.

You need to integrate your changes often, do not wait the end of the day to commit your code. It is preferable if the commits occurred every few hours or even sooner. This way the conflicts you might have will be way easier to solve.

Whenever you want to integrate your code to the source control you have to make sure you have the latest version on your machine in order to check if all tests (acceptance ones included) pass otherwise you need to fix them before proceeding to the commit.

With modern tools at our disposal it is possible to automate the continuous integration process. You commit your changes, then the source control build the application and run all tests. If it is green, the project is deployed (most likely on a development environment) otherwise the code changes are refused and you need to fix the issues before trying again.

Extreme Programming is mainly focused on getting quick feedbacks, with unit tests for the code, acceptance tests for the business requirements. Continuous integration has the same goal of shortening this feedback loop, this practice helps a team to avoid Big-Bang commits with massive breaking changes that lead to compatibility problems, huge conflicts and painful merges sessions.

See you next time!

Image credits:

http://ardalis.com/rgrc-is-the-new-red-green-refactor-for-test-first-development

Book Review: Notes to a Software Team Leader

Julien Fiaffé Books , ,

notes-to-software-leader-coverIn the career of a professional developer there is a time where we are asked not only to produce high quality software but also to become a leader for our team. And this new task requires different skills in order to be achieved, being a leader is not easy and it can definitely be frightening.

In this blog post I will not share my experience regarding this topic. Why? Simply because, when writing these lines, I am not a software team leader. And therefore I cannot give you tips for an experience I have not yet lived.

This article will be about a book that shares the experience of an actual team leader: Roy Osherove. In his book, “Notes to a Software Team Leader“, Roy explains the concept of the elastic leadership and also what are the 3 phases in which a software development team can be.

Why did I read this book?

You might wonder why I read this book about software leadership since I am not a team leader. And I asked myself the same question before reading the book. Well, maybe one day I will be asked to take the role of a leader in a software development team.

I am the kind of person who likes to plan ahead and therefore I decided to read this book about the responsibilities I might have one day. By doing so I will be able to have ideas about what will await me for this challenge.

Also, the two senior developers of my team read the book and they referred to its content. They spoke about comfort zone, commitment language and others topics. And it made me curious, so I decided to read the book to able to understand what they were talking about. And after doing it I was able to understand a bit more their situation and mine as well in the team.

In some software development teams there is no formal team leader, there are only programmers which have to work with each others in order to complete the tasks they have. And sometimes you are the most experienced developer of the team in the company and even if you did not ask for it, you are kind of the leader.

I went through short periods like these ones during my career and it can be stressful because you just don’t know how to behave when facing some situations. Reading the book can be helpful to understand in which phase you currently are and how to get out of it.

Elastic Leadership

The “ultimate” style of leadership just does not exist. If it does we would all know it by now. To be an effective leader you will have to adapt to the context you are working in, the work environment, the personalities within the team and everything that can have an impact on your team. Your leadership has to be “elastic” and you have to adapt it depending on the situation.

In “Notes to a Software Team Leader”, Roy Osherove describes 3 different kinds of leadership: command-and-control leadership, coaching leadership and facilitating leadership.

In a command-and-control mode, the team leader tries to solve everyone’s problem. This looks commendable for your team but it can also prevents your team members to learn anything since you are doing all the work.

The “coach” leader is great at teaching new things to others. He will let you experienced new things and sometimes let you do some mistakes if there are lessons to learn. This mode is helpful for your team but in some situations you can’t do it because your don’t have time for it, there are too many fires to put out.

The facilitator leader stays out-of-the-way. He makes sure that the environment is optimal for its team and relies on the skills on the team members to get things done. This type of leadership cannot be achieved if the developers are not experienced enough to face the challenges they have to deal with.

These three leadership styles can be applied to different phases that a team can encountered during the lifetime of a project.

Survival phase

Does your team spend its days on putting out fires? There is absolutely no time for learning new technologies and technics? Then you probably are in the survival mode.

Even if does not look like the kind of environment you want for your team it can be appealing to stay in it. Why? Because day after day you will do the same kind of work, the kind of work that feel “safe” because you have already done it, several times. You are in your comfort zone even if there are fires everyday.

To get out of this phase, you have to break the circle by providing slack time dedicated to learning. By gaining new skills the team members will be able to deal with more issues they have to face.

For example they can learn about refactoring technics in order to decrease the technical debt of the project. They can learn how to add unit tests to the source code.

You should not see these learning opportunities as a waste of time but as an investment in your team.

The survival phase is the time where command-and-control management can be helpful. You take control of the ship to avoid sinking and you give orders. To correct previously made bad decisions, to avoid mistakes you know will happen. Your job is to get the team out of the survival mode, to aim for the learning phase.

Learning phase

In this phase, the focus is on gaining new skills. The project is more stable than it was during survival phase and you now have time to spend on improving things.

You are no longer needed to apply a command-and-control type of management, you now need to act as a coach. Helping your coworkers to learn is your goal.

When learning you are not increasing your productivity at a constant rate, the curve is more like the one shown on the graph below.

Learning Rate With Ravines
Learning Rate With Ravines

There are ravines before each peak, they are adjustment phases and they might seem painful because your productivity is decreasing. Yet you should embrace them because they are leading you to new paradigms, skills and knowledge, you are stepping outside of your comfort zone.

The learning phase is the perfect time to teach about commitment language. When you will do something, you mean it and you will actually do it! I wrote an article about “saying yes” a while back, where it is all about commitment.

You also have to teach your team to start dealing with its own problems, the one you were dealing with during the previous phase. When a new issue is raised by a member of your team you should give them the following answer: “What will you do about it?“.

This question aims to make the members take actions in order to deal with the challenges they are facing everyday. And they of course have to answer the question using commitment language.

But what if the solution is not in our hands? Then in which hands is it? What prevents you from speaking to this person/team to explain your issue?

Even if in a lot of situations we cannot fix our problems alone, this does not mean that we are powerless. There is always an action that can be done by ourself to get closer to the “fixed” state for our issue.

During the learning phase, the team leader has to focus on the autonomy of its team to make it self-organized.

Self organization phase

When the team enters the self-organization phase, you can follow the facilitating kind of leadership. You act as a guide and remind your team the concept they learned during the learning phase, such as the commitment language.

You do not have much to do, you give your teams goals and after that you just get out of their way. They should know how to deal with the challenges they will face. They will learn the skills they need in order to get things done.

During this phase there is not much else for you to do.

Conclusion

As a software team leader, I think that your job is to strive to create self-organized teams. In a way you have to make yourself “unnecessary” by making your team autonomous. Don’t worry, this is a long and fastidious work so you won’t be unemployed just after a few months. And when you reach this goal, you can take another team stuck in the survival phase and grow the people working in it. There are a lot of software development teams that need your help!

This is just an overview of the book content and I can only encourage you to read it to learn more. I think that it is not only intended to be read by team leaders but also by every professional programmers who is interested by the phases a software development team can be in.

See you next time!

Starting a blog

Julien Fiaffé General ,

home-officeThe first time I was thinking of creating a blog was about 5 years ago, when I was still in computer science school. At the moment it felt like a really good way to get noticed and it is. But the main concern I had at that time was: I don’t know anything to blog about, there were already blog posts about everything.

What I learned since then is that it is not true and it does not matter! A blog aims to show what you are able to do and what are the topics you like.

I finally created my first technical blog about a year and a half ago (yes, that’s a long time after my first mention of a blog). It was in french and mostly focused on web development with ASP .NET MVC. I wrote 5 articles in 5 months… And after that I drop it. I did not have a main theme for it therefore I did not have much ideas for the articles. And at the end I was not motivated to write posts. I did not consider this experience as a failure but more as a learning opportunity.

In august 2014 I decided to fight back by creating a new blog, in english this time (you are reading it) with a more defined theme. I had more motivation to post articles because I had ideas. I’ve been able to post more frequently in comparison of my first blog even if I chose to use a language different from my native one.

I passed another milestone in february this year. I subscribed to John Sonmez (creator of SimpleProgrammer.com) email course on how to create a successful blog. You can access this course by following this link: Create a blog that boosts your career.

Well, I already owned a blog, I did not need to know how to create one. But since it’s free I tested it to see if I could get some interesting advises for my personal website. By subscribing you will receive lessons every monday and thursday with an exercise to complete for each lesson. I liked this format, it provides a good pace.

The first thing to know when creating a blog is to have a main theme for the articles you will write. I lacked this for my first blog and I can only approved this.

The second lesson to learn when creating a blog is to create it! Just launch it, do not be afraid. Thinking of creating a blog is good, doing it is better. You don’t have to wait for 4 years like I did. And since you have a theme, you can register a domain name to match it.

Not having ideas for your blog can be deadly for your site, I experienced that as well. So this is why it is important to have a list of topics with all the subject you want to blog about. When you have an idea, put it in your list. It does not mean you will have to blog about it but it can give you other ideas. I personally use an online kanban board (with KanbanFlow) to keep track of all my ideas, it allows me to access it rapidly and to add new topic whenever I want. You can see my personal list on the screenshot below, it will let you have an idea of what I will blog about in the future.

kanban-list

Consistency is also important when posting articles, commit yourself to a posting schedule. When you visit a blog with no update for several months, it is likely that you will think that this blog is dead.

John Sonmez provides more lessons in is course and this is why I encouraged you to sign up if you want to start a blog but you don’t really know how or if you have doubts about it. Even if I already had a blog when I did it myself I learned valuable things, for free!

Having a successful blog is not easy, it demands time and effort but it is rewarding. At the moment, I don’t consider my blog as a successful one but I own all the keys to make this a reality. And what I know for sure is that I really enjoy posting on my new blog. It helps me improving my writing skills and learning new topics.

See you next time!

Are you a software Boy Scout ?

Julien Fiaffé Development Practices, Software craftsmanship , , , , ,

boy-scout

If you are a developer like me, you probably worked on a legacy code based application. If not, don’t worry (or do) it will certainly happen… We all know a project that we fear to open because it is just a huge mess without a single test and nobody really understand how it works, it just does. Every software team has to work in order to prevent the effects of technical debt.

Refactoring a whole application to make the code “cleaner” can take an enormous amount of time, it can be weeks or sometimes months, depending on the project size and complexity. Some organization will incorporate refactoring phases during the development life-cycle. But since during these periods, the team does not provide any new features (i.e. no value), having these refactoring phases is a hard sell. Time to become a Boy Scout then !

What the boys scouts have to do with software development ? The answer is found in their rule :

“Always leave the campground cleaner than you found it.”

This simple rule can be applied to code and especially legacy code, and it becomes :

“Leave the code better than you found it.”

I present you the Boy Scout Rule (BSR) of programming. Making the code “cleaner” can be done at any moment, and it can be done piece by piece, no need to wait for a “Big Bang Refactoring” phase.

If you have a legacy project it is likely that you will have some improvements or bug fixing to do in it. This is the perfect time to embrace the boy scout philosophy. Of course after your passage the application will still be legacy but a bit less, and the next time you will improve it again. The code will become better with time and one day you’ll stop considering the project as a legacy one.

For example it is possible to rename a variable with a more meaningful name. Given the following code to calculate a triangle area :

var res = b / 2 * h

After the BSR applied :

var triangleArea = base / 2 * height

This is not much but it will help the next developer (maybe you) to understand the code and its purpose. And next time you will see that this piece of code is duplicate in several parts of the code. Time to create a method then :

public int CalculateTriangleArea(int base, int height)
{
    return base / 2 * height;
}

You now have a method that can replace your duplicate code and that can be easily tested with your favorite automated testing framework ! I know that this example is really simple but I’m sure you’ll find these kinds of easy “cleaning” in your applications.

There is a type of code refactoring I often use to make my code more understandable and to ease maintainability : moving repeated magic number value into a single constant variable. For example, a few years back, the french VAT was equal to 19.6% and now it is 20%. I let you imagine the pain it could have been to change every “19.6” in some projects where it could have been far easier to use a single constant with a meaningful name.

There are a lot of refactoring techniques to improve your code base, Martin Fowler gives you a list of some of them here.

A software craftsman does not fear legacy code, by following the Boy Scout Rule he will improve his projects.

See you next time !

Meet your community

Julien Fiaffé Software craftsmanship , , , ,

community

About a year ago I watched a video made by Scott Hanselman and Rob Conery entitled “Get Involved !”. The purpose of this video is to convince software developers to become active within their community. I really enjoyed this video and it made me want to participate more. This blog is the first example of the things I did toward this goal.

If you want to find more information about this subject and watch the video : Become a Social Developer !

There is a whole chapter related to user groups which allowed me to discover Meetup. This network helps you find user groups in your area in almost any domain you like. This way you can meet people who share common hobbies and interests. And if there is a subject you like without a related meetup in your neighborhood, nothing stop your from creating it !

I recently attended my first meetup and it was an extraordinary experience, I came across a lot of interesting people I could not have been able to meet otherwise. It was all about debating, discussing and sharing in a funny and respectful way. The subject of this meetup was Software Craftsmanship and you can find a summary I wrote on my company’s blog here.

I can only highly recommend Meetup to find communities you might want to socialize with.

See you next time !

The Clean Coder : How it changed me

Julien Fiaffé Books, Development Practices, Software craftsmanship , , , ,

“The Clean Coder” is not a book about the code, it is about the coder. A software developer does not only write code for himself, he writes code to solve problems, to add value to his company. In this book Robert “Uncle Bob” Martin shares his experience on the mistakes he did and how he changed his behavior in order to act as a professional.

I really enjoyed “The Clean Coder” because it made me think of my own behavior. Do I behave as a professional ? What can I improve ? What should I stop doing ?

I discovered a definition of “professionalism“ that I was not following, I learned to do “no harm”. I discovered what I implied when I said “yes“ and that I should not be afraid to say “no“. I discovered how to stay focus while coding. I discovered the benefits of Test Driven Development (TDD), the benefits of Acceptance Testing and the benefits of having a good Testing Strategy. I discovered that practicing my skills is key to achieve mastery. I discovered how to manage my time in order to stay productive, how to avoid unnecessary pressure and making concrete estimations. I discovered that collaboration is key to build excellent software and that I have to work closely with my team to complete my projects. I discovered a whole new world of apprenticeship and mentoring : Software Craftsmanship.

This software development ideology suits me, it gave me a path to follow. I decided to sign the software craftsmanship manifesto to be committed and to ask more of myself. Being a craftsman is not an easy task, it is an attitude that has to be learnt. It is challenging and that’s fine to me. I like to be challenged, it allows me to improve.

I hope you liked this journey through “The Clean Coder”, see you next time !

The Clean Coder : Mentoring, Apprenticeship and Craftsmanship

Julien Fiaffé Books, Development Practices, Software craftsmanship , , , ,

Apprenticeship

Software development is a relatively new profession, new technologies and discoveries make it changes constantly. Thereby it has not been codify yet, there are several methodologies, principles, practices and patterns. And this is a good thing, we still have a lot to explore to master and contribute to our craft. Yet, this lack of codification allows us to do whatever we want and sometimes in a bad way. We’ve all seen teams that defined themself as “agile” because they do not have any single methodology and use the term “agile” as an excuse for chaos ! We’ve all seen a two or more years project that does not have a single test ! We’ve all seen programs that become unmaintainable after 6 months of coding ! We’ve all seen projects that have more bugs than lines of code ! Somehow this is the cost of our new non-codify profession. Fortunately there are a lot of well designed, covered with tests, maintainable software too. It is up to us to share our knowledge and best practices with each other, it is up to us to codify our own craft.

Even if software development is new, we all had mentors to teach us programming. We learned through teachers, colleagues, books, videos, articles or even friends. Forty years ago when programming was starting all these resources were scarce or non-existent. Uncle Bob (“The Clean Coder” author) had to learn programming the hard way, without all the resources we can find one mouse’s click away. If we work with senior developers or any experienced professional we can ask them to share their knowledge to teach us how to behave as a professional. And we can of course share our own experience with the younger ones.

After graduation, a medical student is not thrown into an operating rooms to perform brain surgery or open heart surgery even if he as the theoretical knowledges to do it. The medical profession oversees education through intense mentoring. Medical students spend a lot of their education time working with professionals to sharpen their skills. It takes a decade and thousands hours of practice to become a professional doctor. Are we shocked by this approach? Of course not, we cannot even conceive it otherwise. Their work is highly important and we expect them to act as professionals.

In the software industry, things are “slightly” different from the medical system. It is no surprise to see “teams” formed with freshly graduated programmers that are asked to build software even critical ones. Of course creating programs is not as crucial as surgery, there is no life at stake. But bad software can lead to colossal monetary loss, Sony is one example of many. Graduating in Computer Science (CS) gives us enough skills to work in the domain but schools can’t teach us everything about programming. Software development is a complex world that evolves day by day and offers us an environment with constant learning. Creating a doctor-like system for our professions is essential to avoid making the same mistakes over and over.

Software apprenticeship can be a three steps journey : starting from apprentice and moving to journeyman before becoming a master.

Masters have more than 10 years of experience and have worked on different systems, technologies and programming languages. They are able to lead and coordinate several teams. They are responsible for the technical aspects of the projects.

Journeymen are trained and competent programmers, they are professionals. They learn to work as teams and to become team leaders. Their experience levels vary among them, there are former apprentices with little experience and there are burgeoning masters.

Apprentices are programmers that just begin their career. They are closely supervised by journeymen in order to improve their skills and knowledges, pair programming is heavily recommended to do so. They learn how to behave as professionals.

This system is similar of the guilds organization during the medieval era. In the real world this system seems to exist, graduates are supervised by young team-leads who are supervised by project-leads. But most of the time there is almost no technical supervision.

When we build software, we are crafting them, programmers are craftsmen. Craftsmanship is the mindset help by craftsmen, it contains values, disciplines, techniques, attitudes and answers. A craftsman is able to work quickly but without rushing, he also know when to say “no” and to meet the commitments. A craftsman is a professional !

If craftsmanship is your way of life keep in mind that you cannot force other programmers to become craftsmen, and convincing them is difficult. If you want them to become craftsmen you’ll have to show them how it is done and the benefits of it. Then maybe they will join the movement.

This was the final chapter of “The Clean Coder : A Code of Conduct for Professional Programmers” by Robert C. Martin. My next article will be a conclusion about the book, explaining what I’ve learned.