The Software Craftsman (Sandro Mancuso) - Notes

1. Software Development in the Twenty-First Century

The key lessons from this chapters are.

• We must pursue the role we enjoy the most. Instead of getting into the trends or competition. we must make sure we’re enjoying working as the role we purse. Author explain that by downgrading his position from Software Architect to Software Engineer (Writing Code).
• Seniority can’t be calculated based on number of years we spent in the industry but instead it must be calculated by the knowledge we carry in different areas, it could be technical, client relationship, dealing with clients, understanding requirement and arts of making client happy.
• Companies expectation from a Software Engineer is far more different in this era. Earlier Engineer was supposed to do what they asked to do. But Nowadays He/She must be able to communicate with clients, must take some key decisions to satisfy client’s requirements, etc.

2. Agile

Seventeen influential people comes together and decided better ways to deliver software projects.

What is Agile?

Agile is a combination of methodology and techniques that according to context, can helps teams and companies to adapt to the ever-changing nature of software project.

There are two types groups of agile.

1. Process Oriented Agile Disciplines
2. Technical Oriented Agile Disciplines

Process Oriented Agile Disciplines

How teams and organizations work, collaborate and organize.

Types of meetings, Role people should play, way of capturing requirements, velocity of work, plan and divide work, demonstration of progress and business feedback.

It helps teams to keep focus on what is really important and valuable to the business.

Technical Oriented Agile Disciplines

Specific to challenges of developing, growing, maintaining and delivering the software.

Test-Driven Development, Pair Programming, Continuous Integration, and simple design

Help to focus on quality of software and help team to ensure they are building the thing right.

What is it to be agile?

Adapting new circumstances - Tom Glib

Either you do agile or you don’t do agile.

Quick & Short Feedback loop.

Shrinking Feedback loop helps to visualize the problem quicker.

It does not solve any problem but rather exposes it.

It helps to get feedback from multiple sources and that eventually helps to build better software and business.

Impact of Agile after its creation

The fast pace of change is modern software project is frustrating and cost a lot of money.

Software Professionals realized that involvement in business if also important along with writing code.

Software Professional started their involvement actively in planning, estimation, requirements, team organization, analysis, architecture, production, demo and collecting feedback from users and stakeholders.

People Empowerment

Instead of relying on Manager or Team lead to assign task to individuals, We now have backlog of tasks that is prioritized by sponsors and product. The team decides which tasks to work on next, how it’s going to be done, and how long it is going to take.

To achieve all those task by teams feedback loop actively involved.

Professional Evolution

Instead of being specialists, like in the past, companies started looking for generalizing specialists.

Ability to understand business, good communication and more extroverted personality become part of skill that professionals need today.

Agile Manifesto

We’re uncovering better ways of developing software by doing it and helping other to do it.

• Individuals and interactions over process and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Principles behind the Agile Manifesto

There are twelve principles as following

1. Satisfy the customer through early and continuous delivery of valuable software.
2. Welcome late changing requirements in development.
3. Delivering Software Faster (Smaller Time Span)
4. Business People and developers must work together.
5. Friendly Environment to keep individuals motivated.
6. Efficient and Effective method of conveying information and face-to-face conversation with team.
7. Working Software is the primary measure of progress.
8. Agile helps to keep maintain constant pace for sponsors, developers and users.
9. Continuous attention to technical excellence (Optimizations - enhance user experience, cost reduction)
10. Simplicity: maximize the amount of work not done is essential.
11. Best Architecture, requirements and design comes out from self-organizing teams.
12. Constant improvement on how to be come more effective and act accordingly (Retros, Faster Feedback).

The Agile Transformation Era

Agile was a major revolution in our industry. Companies started adopting it. Companies and individuals became specialized in helping companies to go through Agile.

While was growing Scrum entered in the market and that was the great entry point into the Agile Word.

It helps teams to control backlogs, estimating tasks, helping prioritization, testing and demonstrating implemented features at the end of each iteration. Communication is also improved.

Team member started communicating more with other team members and customers. This more interaction leads to understand weaknesses and strengths of teams and individuals. (Retros)

It helps to provide feedback to react and adapt.

The Agile Hangover

After following agile, companies were transformed.

Meetings Stand-up meetings

Iteration backlogs and release backlogs new project management tool.

Use cases User stories

Project Manager Scrum Masters

More members comes together and working on single computer and whiteboard.

After some point of time, companies realized that after all these transformation, they are still not delivering software with good quality and fast enough.

Motivation was a big problem, but still many companies kept using Agile Fashion.

The list of bugs was not smaller that it was before. There were lots of complains about expense, slowing the business down.

The new application built in with Agile fashion were badly designed, complex and buggy as the application developed before the agile transformation.

Now the question was, how do we solve this problem?

A Partial Transformation

People wanted prescription: Something that they could follow to magically make them better.

People just forgot that in a software project, the most important deliverable is the software itself.

The Partial Transformation was causing all the problem and that eventually leading to bad software quality and slowing down the process.

Agile transformations were focused on process but not on technical disciplines, which means that they did very little to make developers better, Software part was stuff was totally forgotten or dismissed.

According Many Agile Coaches: Promoting communication & empowering people solves all problems. Let’s improve process and everything else will be OK. and there were wrong.

The context behind Agile was mistaken, Companies focused on process, prioritization, visibility of Work in progress, etc.

Process became more important that the technical excellence.

Coaches were selling Agile with Toyota Dream. How they had successfully became changing their process, reducing waste, limiting work in progress, etc.

Building car != building software, There is no serving in between the development. There is no interaction with company after building car (Add one more door).

An important factor to Toyota’s success was, besides a good process, the focus on the quality of their cars.

Focusing purely on the process and treating software development like a production line leads to average 9-to-5 developers doing what they are told—they become factory workers.

Agile Coaches

Every profession has good and bad professionals, the difference is, Few fully understand the Agile and advising companies to focus on process and technical excellence. Majority will focus on process only.

Senior Managers understand processes really well, they’re failed to understand importance of paying attention to the quality of the code produced by the developers, as long as it’s working, they’re happy.

When Senior managers coming from nontechnical background, they are easy to convince by coaches. When Agile goes wrong, it’s easy to blame developers. But the question should be how do we make it better?

Rejecting Technical Practices

There is other side as well, there are good coaches who are doing excellent job.

Some companies take it other way, why to waste money in having two developers pairing together.

They don’t know the benefits of Test-Driven Development.

Sometimes developers don’t want to accept pairing, they might think that they expose their weakness.

Manager’s idea of a senior and experienced developer

3. Software Craftsmanship

Software craftsmanship sees Software as a craft and software developers to medieval blacksmiths.

It’s all about being responsible for their own careers, constantly learning new tools and techniques. constantly bettering themselves, professionalism, pragmatism, etc.

Software Craftsmanship talks about

• Caring what they’re doing
• Always trying to be better themselves
• Being Professional
• Helping Customers Achieving their goals
• Mentoring less-experienced developers If you always values the things above that is great. You’re a Software Craftsman.

Author visited apprenticeship summit in North Carolina, conclusion was a call to action to form a community around software apprenticeship.

The company, The 8th Lights started Software Craftsmanship company from start and hired some apprenticeship and disciplined talent. this action was noticed.

There was a Agile Summit, as a conclusion, Extreme Programming(XP), Commercialization and process-oriented methodologies like Scrums started bothering some of original Agile innovators.

in Agile Summit there was lot of talks about Software Craftsmanship which led to more Software Craftsmanship Summit to formalize and better define it.

Summit was organized near Chicago, it went near about 6 hours and after that there were 30 peoples including Uncle Bob and others. They immediately started discussion on google group about Software Craftsmanship and there were some people from UK to contribute. After that It was spreading in UK and to the world.

Craftsman Swap

In one of the event in Chicago, There was discussion around Craftsman Swap, There was a mutual respect between two companies, in terms of technical capabilities, Which made them believe they could learn a lot from each other.

When obvious that This method most probably leads to competing against the people out there whose main goal is to earn as much money as they can.

They did’t really care about How Software will lives over a long period of time. They just wanted to push out software really fast without thinking anything else.

Developers involved in swap process worked as normal Developer. They were…

• Pairing with other developers
• Doing real work
• Writing code
• Going to meetings They were behaving like they are working for other company for that period of time.

This method helps then learning new development styles, new languages, new tooling and so on.

It’s more beneficial to Engineers rather than company.

It makes tons of sense to Software Companies to follow Swap. if they don’t have direct competition.

As a result of following Swap, It helps Craftsman to learn new practices and tooling and improve their own.

After completion of Software Craftsmanship Summit, There needs to write down Goals of the Summit.

Various people participated and shared what they means about Software Craftsmanship.

Initially all things wrote down on a white board and get signed by various people.

The Manifesto

Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft.

• Not only working software, but also well-crafted Software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions but also a Community of professionals
• Not only Customer Collaboration but also productive partnerships Developers also taking matter in hand by not just proposing new and revolutionary process but also by showing their customers that they care about what they do. The code must be maintainable and predictable. Developers must know what is going to happen when changing the code and must not be afraid to change it. Using Test-Driven Development, simple design, and expressing the business language in code are the best ways to keep a healthy and well-crafted code. Software projects are really expensive, developers, QA, managers, advisors, marketing teams, R&D teams, Imagine the salary of all those people. Moreover expense of Office, Software Products and traveling also includes here. It’s our job to…
• Constantly improving the structure of the code
• Keeping it clean, extendable, testable and easy to maintain
• Older and bigger the software gets, the more the company will benefit from it.
• We have to maintain the same speed of developing features and appropriate changes to the application.

Good software design, automated testing skills, and passionate and talented developers are essential for achieving that.

Totally rewriting a large application a few years after it has been developed makes for a very poor return on investment.

Sharing and mentoring are at the heart of Software Craftsmanship.

Learning from each other is by far the best way for us to become better. Writing blogs, contributing to open source projects, making our code publicly available, becoming part of our local communities, and pairing with other developers are some of the ways we can contribute to the greater good of our industry.

4. The Software Craftsmanship Attitude

Owning your carrier is in your own hand. Companies are helping their employee to learn and gain knowledge by sharing courses, books, and giving chance to work on latest technologies.

Relying on companies to provide you learning is never a good idea but Professionals need to invest in their own careers. So…

• They can do good job
• satisfy their client
• may be refer some other clients.

We must spend own money and time to learn new stuff and gain knowledge.

Gained knowledge & learning will never get wasted.

Knowledge and skills will ultimately reflects to success of company.

Employee - Employee Relationship

Instead of following old management where People are keeping their head down, working hard for 9 to 5 and doing only what they’re told to do.

Developer want to be treated as professionals, they should start acting as professionals. for that they should…

• Involved and contribute to business
• Provide options and solutions
• Offer best server when it comes to implementation
• technologies and quality of what we produce.

Keeping ourselves up to Date

Different people have different learning patterns and preferences to learn new stuff. Some follow books, articles, video format, etc.

Books, Many Books

There are various types of books and choosing which type of book to read is difficult task.

• Technology-specific Books
  • Kind of expired due to rapidly evolving tech
  • Gives deep understanding of how things works
  • Gets old quickly when a new version released
• Conceptual Books
  • Foundation to advance in our careers
  • Introduced to new concepts, paradigms and practices
  • eg. TDD, Functional Programming, Domain-Driven Design
  • Learning new paradigms is far harder than learning a specific technology
• Behavioral Books
  • Makes more efficient when working in teams and better professionals
  • Teaches how to deal with people, clients, deadlines and team members
  • Knowing programming languages, frameworks is not enough, we need to learn other stuff too.
  • eg. Agile methodology, Software Craftsmanship, etc.
• Revolutionary Books
  • Change the way we work or even some of our personal values.
  • Expected to read by every software professional
  • eg. The Pragmatic Programmer, Design Patterns, Test-Driven Development: By Example Extreme Programming

Blogs

Blogs are extremely popular and a great way to keep ourselves up to date.

Reading blogs from more experienced professionals and subject matter expert is good, quick and free way for us to learn from great professionals.

Blogs can be dangerous as well, It may be written without much research or deep thoughts.

All software developers should have their own blogs.

We shouldn’t worry about what people will think about it, We should first write it for ourselves.

Know Who to Follow

There is a group of people that contribute massively to move that profession forward.

That helps us to filter the information we have online or in physical books.

You’ll get to know lots of stuff such as ideas, reaction on new launching stuff, etc.

Twitter is a great tool for learning from others.

Practice, Practice, Practice

If we want to be good at writing quality code, we need to practice how to write quality code.

Helps to build muscle memory and that will become habit.

Don’t focus on the problem but instead focus on techniques.

eg. While driving car for the first time, you’re thinking about how to drive, where to go instead of mechanics working behind the scene.

Technical Practices and New Technologies are the same thing. The more we practice, the more comfortable we become.

Katas

Katas are simple coding exercises.

Some people thinks that it’s like doing stupid thing again and again. And it’s true at certain extend.

The word comes from martial arts and that is how it is done in karate. They practice same move again and again to master it.

When doing katas, the idea is that we stretch ourselves, using practices, techniques, and technologies that we are not very comfortable with, with the intent of getting better at them.

Katas can be more effective if we follow it multiple times with different techniques and approach.

Pet Projects

Project without pressure and deadline. It’s by far the best way to learn and practice.

It’s not for money and fulfilling requirement rather it’s more for learning technologies and methodologies.

It allows you to experiment, learn and play in safe environment.

Picking up Pet Project’s problem statement is also important (not necessary think about business).

We think about…

• Tests
• deployment of application
• version control
• continuous integration
• usability
• user interface
• infrastructure
• code design
• databases etc.

Open Source

Contributing to open source project is also a great way to practice.

You can inspect, debug and play with code. If you want to contribute start small: add some documentation, add some tests, check list of bugs and good first issues.

Great thing about open source project is, you get to see great developers in action.

Looking at how they code and solve problems can be great way to learn.

Pair Programming

It’s more a social activity than a technical practice.

There is a limit to what we can learn on our own, certainly we can learn anything but it takes a lot more time if we consider learning our own. In addition we will always have naive and biased opinion.

While paring, we can learn how new language or part of the application to which we had no previous exposure and a technical practice like TDD, Keyboard Shortcuts, some ways to deal and search about problems, etc.

When pairing, we get immediate feedback on our code and ideas.

A good developer is a developer who can write code that any other developer can understand. When pair don’t agree or don’t understand, it’s an opportunity to have good discussion.

Pairing with someone from our team or a friend is great, but pairing with someone that we barely know can be even better. You’re exposed a complete different way to think and solve the problem.

We need to keep our minds open to new ideas when pairing. Sometimes we learn, sometimes we teach, and sometimes we do both.

Socialize

Socializing is a essential for a successful career. A great and easy way to do that is to join your local user group and technical communities and to participate in their events.

The great thing about passionate developers is that they are constantly learning and are very happy to share what they know.

Deliberate Discovery

I’m the smartest man in Athens because I know that
I know nothing. - Socrates

The biggest mistake that software professionals can make is not accepting that they don’t know what they don’t know.

if we reduce the level of our ignorance as fast as we can, we can be far more productive and efficient.

We should always try to create opportunities where we can learn something we don’t know. “But if I don’t know what I don’t know, how can I create opportunities to learn that?”

eg. We have written code that we think it’s the best code, and it’s kind of based opinion unless we show or get it reviewed by other people. When they gives us feedback we would think of other aspects as well.

Work-Life Balance

It’s important to take some time to invest on our self in terms of learning new stuff, keeping ourselves up to date in tech.

Instead of complaining that we don’t have time, It’s always better to accept that we all have time. We’re not good at optimizing it.

Creating Time

Due to laziness and procrastination, We avoid such productive work we want to do.

In order to realize the time we waste, we have to analyze it. You may be read books, articles and watch videos at lunch time or may be before going to bed.

May be scroll Twitter for good purpose. Focus: The Pomodoro Technique

• Decide on the task to be done.
• Set the pomodoro (timer) to 25 minutes.
• Work on the task until the time rings.
• Take a short break (5 minutes)
• After every four pomodoro take break (15-30 minutes)

Balance

If you’re be like “I don’t want to touch a computer outside work.” then you probably should think again about your career choice, may be Software Development is not for you.

Keeping our professional life healthy is essential for a healthy family life.

5. Heroes, Goodwill, and Professionalism

Learning How to say No

When we have unrealistic deadlines, often young developers tend to saying yes in pressure.

Main issue arise when developers are aware that It’s unrealistic and they agree and committing to complete unrealistic stuff, which eventually leads to negative impression. How “Saying No” is so essential?

The very same manager who pushed developer to work offsite, in-pressure and what not. Meanwhile manager is enjoying at home spending time with loved ones. Still He will complain about may be How you break the validation on Sign up, How system isn’t able to process 10k request in a minute, How could you forget about edge cases? and so on.

All these things can be avoided by saying no and giving alternate solution of the problem.

A Epic Failure

A development team at a large telecommunications company was assigned to create a mobile portal for simultaneous launch in three countries. Despite the team’s warnings about the unrealistic deadline and the need for infrastructure work, the manager insisted on adding more features without moving the launch date. The team worked long hours, neglecting essential testing and preparation.

When the application launched, it couldn’t handle the load, resulting in frequent crashes and customer complaints. The development team was blamed, leading to resignations and the company having to hire new developers quickly, who were unfamiliar with the system’s issues.

The marketing team later revealed they would have adjusted their demands if they had known the technical constraints. The rushed development process resulted in a delayed second version of the application, taking nine months instead of the planned three.

Lesson Learned

We can immediately say that the manager did not act professionally. We can say he never cared about the team and was just trying to get his own promotion while other people were doing the hard work for him.

Developers should have never said we would try to complete or never commit if they already knew it’s impossible.

Team of Developers wanted to show how good they were. They wanted to be heroes with small percentage of chance.

In this Story, Manager was aware that developers don’t have bandwidth despite he was not transparent with marketing team.

Being Professional

Very often we have to deal with very hard deadlines. The best way to deal with them is to analyze everything that needs to be done and communicate all the possible risks we see and concerns we may have.

We also need to analyze How much we confidently deliver by certain expected date.

Sometimes, Managers use can-do attitude to motivate developer to get something done. And Guess what most of the time developer respond “OK. We will try our best.”

Setting up deadline must be in specific time range instead of fix and strict time.

In The Passionate Programmer, Chad Fowler says that saying yes to avoid disappointment is just lying.

We usually do not like to say NO. It sounds wrong and may get negative impression.

Professionalism means being honest with ourselves, with our teammates, and with our managers and customers.

If we feel that our manager is not being transparent to boss and other teams. Instead of just focusing on the best impression we must address current issues and focus on being transparent.

Negotiation is a skill we all need to learn. It helps to build trust, confidence and credibility.

As long as we do it in an honest and transparent way, there is a big chance that no one will get hurt and the whole team and the company will win.

Providing Options

Always saying no is also not a professional attitude. Before saying no we have to analyze the problem and provide options.

It may not be possible that we comes up with viable options (alternative) but incomplete ideas can help other people to find a different alternative.

eg. A boss asked two assistants to buy him an orange juice. The first assistant quickly returned, stating that the nearby shop had no oranges. The second assistant took longer to return and explained that while the shop didn’t have orange juice, they offered fresh pineapple and bottled apple juice. Additionally, she found a nearby supermarket with fresh oranges and offered to make a fresh orange juice in 30 minutes, providing the boss with multiple options and asking for his preference.

Being honest, no matter how bad the situation is, is a sign of professionalism.

An Unexpected and Viable Option

Working on a project for an investment bank to report trades to regulators, the team faced a stringent externally set deadline. The penalties for missing this deadline ranged from steep fines to losing the ability to trade certain products, which would severely damage the bank’s reputation. Despite having a talented team and working hard, it became clear that they could not automate the reporting process for all types of trades required by the regulators.

Under immense pressure from the business to work extra hours, including weekends, the team had to make tough decisions. They decided not to relax their coding standards or work over the weekends, knowing it would lead to burnout and compromise the quality of their codebase, affecting future deadlines. They communicated transparently with the business, showing the project’s progress through their Agile Kanban board, which helped illustrate that even working seven days a week would not suffice to meet the deadline.

As panic set in, the team explored alternative solutions. They discovered that regulators accepted manual uploads of trade reports via CSV files, a method initially dismissed due to the high volume of trades. Given the progress already made in automating most trade flows, the team re-evaluated the manual option for the remaining trades. They concluded that hiring staff to handle manual uploads was more viable than risking penalties, and this hybrid approach allowed them to meet the deadline.

By saying no to unfeasible demands and being transparent, the team found a balance between automated and manual solutions, which allowed them to comply with the regulators’ requirements on time. This approach provided the necessary breathing room to automate the remaining manual processes incrementally, ensuring quality and compliance without compromising their standards.

Enlightened Manager

Good managers understand that they are part of the team and need to work with the developers toward the common goal.

Managers should appreciate when we say we cannot deliver some features.

Transparency helps managers and the team to prepare for tough situations.

If we manage to deliver what we promised when we said yes, managers will be far more inclined to trust us when we say no.

If Manager understand and expect that certain things are not easy to do or may take a long time to be done.

Good Mangers are part of team and they stay with team in good and bad times.

6. Working Software

Traditional Mangers and business consultants can say whatever they want about the importance of a good process and documentation but the truth is that in a software project. Because the most important deliverable is the software itself.

Many Companies are not realizing the importance of having great people working collaboratively. (TDD as an example)

Working Software is not enough

In Agile Manifesto we have…

• Working Software over comprehensive documentation

Deliver working software frequently (week or month), with shorter timescale.

Working Software is primary measure of progress.

The Working Software moved away from high-quality Software. They aren’t up to the mark as expected by Agile Project.

• Adding a new feature takes a long time
• Application are fragile or tightly coupled
• Application force you to test manually
• Need to deploy into user acceptance testing (UAT) etc.
• For testing we can’t run it locally They all are working software. What is exactly “working Software”? the one described above?

Looking After Our Garden

Rather than construction, programming is more like gardening. - The Pragmatic Programmer

Like a garden, code needs constant maintenance.

For a garden to look beautiful all year around…

• Need to look after its soil
• Constantly remove weeds
• Regularly water it
• Remove dead plants
• Plant new ones
• Trim or rearrange existing ones, etc.

If we neglect above stuff for even short period of time, next time we need efforts to make it healthy again. If we neglect for longer time, efforts required will be exponential.

For code it’s also same, Bad design choices, lack of tests and poor use of languages and tool will make the code rot faster.

As you start neglecting these stuff the whole code base will be extremely ill, making it painful and costly to maintain it.

The Invisible Threat

When starting a new project, everything goes well and fast because there no need to look for existing functionality to break, testers are happy because they don’t need to worry about regression tests.

However, Team is composed of average developers, selected by matching set of keywords against their CVs and Salary Expectations.

As time goes by, things become messier, bugs start to appear and features start taking longer and longer to be developed and tested.

It’s very common to see project where, a feature of size X takes N number of days to be implemented. Over time, as bad code is added to the application, another feature of size X takes longer than N number of days. The reason is simple, as the quality of code decreases, the amount of time to implement new feature, fix a bug, make a change increases.

Some people argue that they don’t have time to do it properly, but it like they always find justice the amount of time and money spent on long testing and bug-fixing phases.

They say “First there is a construction phase then testing and then stabilization phases”

Hostage of Your Own Software

When the code gets into situation where changes or adding new feature take too long, developers are scared to touch existing code base, action must be taken immediately

Because this situations directly impact business, and that’s dangerous.

“In order to increase business agility and have a good return on investment, keeping code quality high is paramount.”

Sometimes manager refuse to take problems expose by developers due to lack of understanding of potential cause or inability of developer to explain it.

Hire a Craftsmen, Not average Developers

With tools, techniques and infinite amount of information available on internet, we can’t let our code rot. Craftsman are gardeners.

They aren’t afraid to quickly refactoring without fear, writing tests that can test the entire application in just few minutes, Time constraints and requirements will never be used as an excuse etc.

Having an empowered team of craftsmen can be the difference between success and failure of any software project.

The Working Notion of Time

Author was working with a developer, who wanted to implement brand new feature. There wasn’t any necessary to touch existing code-base despite adding new feature.

Author offered Pair after 2 days and noticed…

• There were no tests
• There was a code which wasn’t required for implementing new feature (added to future)
• Developer wasn’t able to explain what sort of feature he was working on

Finally they decided to add refactoring and adding test in technical backlog.

Adding items to a technical debt backlog is a way that developers have to justify the bad code they’ve written without ever feeling guilty about it.

We want to do the right thing

Usually, Developers have a wrong notion of time, they always think we are under pressure, We always feel we need to rush. Most of the time pressure is self-imposed.

Despite being everything transparent we think we have to rush to deliver the task we committed.

We normally feel that if we deliver fast, we’re doing good job. We feel meeting a promised deadline with potentially buggy solution is better than being honest and transparent.

A Busy Team with No Time to Spare

When author started working for a new company, He wanted to setup project locally. The project was nightmare to configure in IDEs.

Project includes more than 70 Maven Projects and modules and large number of dependencies.

Author asked for a engineer for pair (not common there), Author notices that that guy was using Testing Environment to test and develop application.

Author asked Why don’t you run it locally instead of Testing Environment, the guy answered It’s not possible to run it locally.

He was adding tons of logs to ensure that system is executing particular block of code.

If something fails, he again fix and add bunch of logs to see it’s working.

After sometime, Author asked Why are you not writing unit test, He replied “it needs to ship quickly, I don’t have time to write test cases”.

After 2 days the issue got finally caught and fixed. There were still easy edge cases bugs that could be easily catch immediately with unit tests.

People were working from multiple countries on single codebase.

You can Imagine the wastage of time for every developer just because they don’t have time to write test and all.

For the quality assurance (QA) team, because apparently testers have all the time in the world. They had to manually test the entire system for every single change made.

Every time a tester finds a bug, developers should feel bad about it.

Although it is important to have debugging skills, we should be unpleasantly surprised whenever we need to resort to that, and when it occurs.

In the years since I became proficient in Test-Driven Development (TDD) and in retrofitting tests to legacy code, I probably could count the number of times I had to debug code.

The Unit Test Task Card

Generally people break down writing Test and Coding part into separate task, We should never do that.

We can’t say that a coding task is done if it is not tested.

Unit tests are one of the best way to make sure that code works.

If writing Unit Test is a way that team agreed to verify that the code implemented works, unit tests should be part of coding task and not a separate task.

Sometimes, it can have negative impression of having separate test on the board, other people might not understand implication of the same.

Sometimes, without even considering the implications of not having tests. They just think about their own tasks, not about all the other people involved in the project and all the time they will spend testing and debugging the system.

What is easy or clear for one developer may not be so easy or clear for other developers on the team, and as the system grows, everyone will pay the price of these small selfish decisions.

Using Time Wisely

Out Clients and Employers are interested in Software that satisfies their needs. They want software that can be changed almost as fast as they change their minds.

We can always quantify how much time we are spending in repetitive tasks and show our clients how much it is costing them.

We should ensure that we provide

• Well crafted-solution
• Good Service
• no false positive impression etc.

We need to optimize from our front to ensure everything stay healthy.

In Devx we also mentioned that having efficient test increase our productivity. As author mention that their test were talking 4 hour to run and still they were broken test suits.

If someone really cared about it, It could complete it in 20 minutes and have broader coverage of tests.

It also helps other teams to carry on and understand or ensure working of existing system.

As author mentioned that A different team is not very close to achieving a “one button” deployment and has extensive test suits with almost 3000 tests including Unit tests and System tests with near to 100 percent coverage.

Legacy Code

Author asked a question in one of the talk, How many people like to work on green-field project?

Lots of people raise their hands, and other question was How many people like to work on legacy code? People kept their hands down.

It’s always nice to work on green-field project.

• Use latest technology and framework
• Not worrying about existing Code-base
• No need to understand existing Code-base
• Progress is made quickly and naturally

Imagine Legacy code with no test and documentation, Of course the number of WTFs increase per day. Frustration becomes a constant.

A Change in Attitude

If you don’t like something, change it; if you can’t change it, change the way you think about it. - Mary Engelbreit

When looking at legacy code, instead of moaning and getting frustrated, we should try to understand it and make it better, constantly applying the Boy Scout rule of making it better than how we found it.

When keep getting little understanding, What before was a bunch of random pieces (or a big ball of mud) is now a bunch of smaller groups of not-so-random pieces.

Bit by bit we start working on one of these group and we start refactoring and making it better. We start seeing a small part of our picture.

It become a story when you gradually understand more stuff. Now you could even introduce the cool and new frameworks that we always wanted to use.

Another interesting thing about legacy code is that it forces us to think in a different way.

Personal and Client Satisfaction

Refactoring code can sometimes be a lot of fun and also very addictive.

The more we improve and keep the software clean, the longer the client will be able to benefit from it.

At the end of the day, it does not matter if we are working on a green- or brown-field project. It’s our attitude toward our job that will make it more or less enjoyable.

7. Technical Practices

The Right Things versus the Thing Right

The feedback loop provided by process-oriented Agile methodologies enables us to regularly inspect whether the business goals are being met.

With some exceptions, Agile Methodology is good because it focus on lots of things like…

• User Stories
• Backlogs
• Stand-up meetings
• Acceptance Criteria
• and what not Instead of document based or classic waterfall pattern.

The problem is that we can’t measure the quality of our application through the practices and activities mentioned above. Eventually, It will get difficult for the business to identify and quite easy for developers to disguise.

So how can we make sure we are building the thing right?

Context

Software Craftsmanship, besides promoting a more professional and ethical attitude, also strongly encourages the adoption of XP practices like Test-Driven Development (TDD), pair programming, refactoring, simple design, continuous integration, and many others.

Generally, Developers don’t use XP Practices on a daily basis.

Commonly everybody says, “These stuff don’t work for my company, I follow complete Software Craftsmanship Idea but other developers are not following, My boss would never allows us to do that.”

Author mentioned that after working for so many companies, they get to know that although various companies has their own way of working but there are lots of things which are common like they’re not happy with delivering the software, lack of agility etc.

They’re always looking for magical solution that can make them better.

The reason can be they are not focusing enough on software being developed.

Having context really make sense, because with that ultimately you will be able to ship software product as per requirement and satisfy client.

Q: does context always matter?

Every company wants good return on investment and that’s where context really matters.

Extreme Programming History

Kent Beck, introduced and combined a set of practices that originated XP. He became leader of C3 payroll System.

The multi million-dollar C3 project needed some high-caliber developers working together, as opposed to working in competition and isolation.

With a big focus on continuous integration and unit testing, they managed to keep the project on track.

Due to its success and unconventional practices, the C3 project was considered an anomaly but as Don wells moved to ford.

Besides Unit Testing and Continuous Integration, Don also added collective ownership to the XP Practices. This went very well.

Since Agile summit in 2001, XP has been considered as Agile Methodology.

XP got ignored by agile coaches and consultancy companies, the truth is very few agile coaches and consultancy companies are good enough to teach XP practices.

People were not caring about XP Practices, focus was on process. now there are couple of questions raised.

• Was XP hard to explain to Business people?
• Were they too hard to sell? etc.

At the end it doesn’t matter, What matters is that software craftsmanship brings the focus back to them.

Practices and Values

When it comes to the quality of our software and making sure we are building the thing right, XP practices provide us with many ways to shorten the feedback loop.

Practices shouldn’t be forcefully applied, then it’s make no sense and doesn’t guarantee success.

Practices are what we consistently do on a daily basis: we either do TDD or we don’t do TDD; we either have continuous integration or we don’t have continuous integration. Some people say, “We do TDD . . . sometimes.” That doesn’t help.

If Practices follows partially, it’s difficult to measure what is working and what is not working.

Practices should be backed by values, It should be shared with all team members. e.g all team member want to better at improving communication, to have quicker feedback, to achieve result faster. to deliver fast to the client. Theses are values. Q: How can I convince my team to adopt TDD, Pair programming, Continuous Integration?

Most of the time talking about practices in-front of manager and business people become useless. Focus on the benefit they bring and how they compare to the practices they currently have. A smaller feedback loop; a better understanding of requirements and cost; knowledge sharing; reduction of bugs; and quick and totally automated releases to production are example of values added by technical practices.

Adding Value through Practices

![[Pasted image 20240624102304.png]]

Automated Testing

Automated testing enables us, with a click of the button, to have our entire system tested within a few minutes.

It gives confidence to deploy our application into production minutes after the last change was made.

Feedback loop on the correctness of our code is reduced from weeks to minutes (reducing error and bug-fixing code at significant level).

Writing tests before writing any production code makes us faster as the system grows.

Adding new feature confidently without breaking the system. Since the entire test suite normally takes just a few minutes to run.

Automated testing gives us measurable business value.

Test First

Test first helps us to think out our ideas; to focus on a single thing at a time.

Since each test takes from a few milliseconds(Unit Test) to a few seconds (High level test), it gives us quick feedback loop when writing production code.

It reduces complexity and over-engineering.

Test Driven Development

Test-Driven Development is an evolution of test first.

Although TDD has “test” in its name, TDD is actually a design practice. When test-driving our code, it becomes very difficult to write complex code.

When test-driving a change or a new feature, we get immediate feedback on how maintainable the existing code is.

TDD offers us a quick feedback on the design, simplicity, and maintainability of our code.

It provides a living and executable documentation for our applications and, as a good side effect, a rich suite of regression tests. That’s value to the business. That’s a quick and short feedback loop.

Continuous Integration

It’s an essential technique when we have multiple developers working world wide. How do we make sure that every team adding feature is working at final stage.

Typically, we have QA teams who reports to developer in case of any issue, although it takes some time to analyze and report (may be some days to weeks).

Continuous Integration, combined with TDD can reduce this feedback loop in minutes. Every time a developer commits some code, the entire suite of test is executed and an email is send to the entire team whenever a test fails.

This builds “stop and fix” attitude: Members of the team must stop whenever they are doing to fix a broken build. The main advantage of doing this is, We can ensure problem introduced by latest change and it always keep system in deployable condition.

In addition to that, the combination of continuous integration and TDD can make an entire QA team redundant.

Pair Programming

Code review is a common practice adopted by many teams in order to guarantee code quality.

When reviewing code may be in mob review or normal review, It’s more likely to have change if the team is full of opinionated developers. It’s common to have change in this type of condition.

Now, after reviewing and suggesting changes it’s again time to do the same, now it’s visible the time wastage on this process.

Pair Programming has the advantage of giving immediate feedback on the quality of the code being written.

As soon as some mistake made, other pair programmer noticed and get back to you on that immediately.

Sometimes, you need to explain what’s going on which makes us clear more on the approach.

More effectively, Pairs should not stay together for too long. Routing pairs frequently - every day to two, can improve the collective understanding of the entire system and level up developers to define and maintain coding standards.

Refactoring

The Boy Scout rule says: “Always leave the campground cleaner than you found it.”, This is a value that every software craftsman must have when it comes to code.

Developers are less inclined to make improvements to code that they find difficult to understand. Because of the fear of breaking the code, they introduced duplication of the code, eventually leads to messy code, ultimately degrade developer productivity and business down.

Constantly refactoring code should be second nature of the developers, if this applied from beginning of the project, developer will never waste time on refactoring because code is always in a good state.

Refactoring without pragmatism can be a dangerous practice. We have to analyze which code to refactor, If a code which is not even touched for years, It’s not good idea to refactor it. Start refactoring what changes more often.

A clean and maintainable code enables developers to go fast and reduces the chances of new bugs. That’s value to the business.

Accountability

Generally, There are some people at higher level or developer side who don’t want to apply these practice, they always say “It is easy to build software without these fancy practices.”

But this is vague statement, We can search on internet about the ratio of failing software projects.

When it’s coming to discussion regarding the not following practices, We should ask, should we go instead that gives us the same or more value than that? We should propose the solution that makes software product better.

From Developers to Manager everybody should be accountable to their decision, people should understand the values it brings to the table.

Pragmatism

Technologies, methodologies, and practices are constantly emerging and evolving. There is always a better way of doing things.

Being pragmatic is one of the best qualities that a software craftsman can have.

We should constantly look for ways of doing our job better and satisfying our customers. If that means TDD, we should use TDD. If there is something else that is helping more than TDD then adopt that.

Dogmatic thinking is bad. We should constantly ask ourselves why we are doing what we do. Is there anything we can do better?

Q: How do we know that one practice is better than other?

Ans: Compare the value they both bring to the project, then compare how long their feedback loops are.

As many agile methodology have taught us, we inspect and adapt.

If we find a practice that is better than what we do today, we adopt this better practice.

As software craftsmen, we should always keep an open mind and choose the best technologies, tools, processes, methodologies, and practices for the job.

8. The Long Road

Everybody wants to be good at something. The motivation may very a little but one thing is true for all of us: Mastering something gives us pleasure.

A Tale from a Brazilian Teenager

When Author was living in small town in Brazilian Side country. He had a dream to visit London. But due to his financial condition It wasn’t possible. London fascinated author such that it was became a dream to visit and work in London for author.

The problems were, He wasn’t neither able to speak English nor had UK passport.

He finished his schooling and decided which career path to follow. Due to financial conditions he had limited options to choose, from those limited options he choose Software Engineering career. He could not afford to study in good university due to financial problems.

After few years working as a Software Engineer. He finally could afford to start very long and expensive Italian citizenship process. It was required old documents of relative for the process and Author spent good amount of money to follow the same.

In 2000, Author visited UK on holidays at that time He was 23 years old. He wanted to confirm that London is that good and fascinating as he though of?

He had traveled nearby places, talked to software people over there and found that He was facing problems speaking in English and not able to understand what they’re saying.

Author mostly worked on Delphi, and found that it is almost not found in London, Whole market was of Java.

Author came back to his country and start learning Java and had private teacher who taught him English. After he decided to take few Java certifications as well that were attached in CV.

At this point he realized how important his career was for them. He was preparing himself to have successful career in London. He came out from comfort zone and took ownership of his career.

He finally moved to London when he was 27 years old professional software developer.

Focus and Determination

There is a well said, “You’ve got to be careful if you don’t know where you’re going because you might not get there.”, We always values and control our careers, It may or may not lead us to mastery.

It’s obvious that we might forget long-term goals and many thing can change. but consider career as multi-year project.

Once we understand the ultimate goal, we can take the most important requirements, break them down into smaller pieces and iterate, evaluating the project goals and adapting when necessary.

But What if We Don’t Know Where We Are Going?

In this constantly evolving field, it’s important to reevaluate our career decisions based on not just our passion but also all the events in our personal and professional lives.

We always have to be active in creating opportunities for us. We just keep sitting in corner of room and waiting for opportunity, no one is aware about it and get you opportunity. We need to show people what we do and how well we’re with what we’re doing.

Here are few things we can do in order to create opportunities.

• Expand our technical knowledge
• Attend user groups and tech community events
• Network with other developers and business people.
• Blog about things we are learning and doing
• Contribute to open source projects.
• Developer projects and make them publicly available
• Attend Conferences
• Present at a Conference.

These are some of the things that helps to create opportunity.

Job as Investment

Each one of us has a different dream, aspiration and different personal situation.

The most important thing is to treat every single job as an investment, a step toward a bigger goal.

We need to be clear about what we expect as a return and we need to measure it regularly throughout the length of that investment.

Author started working for investment bank, people around them surprised to see author working for investment bank, Company was looking for someone who can build strong technical practices along with agile methodologies processes.

Author wanted to fill some gaps in his career by doing relevant jobs. He was expecting good return on investment as experience in developing software at a very large scale, work with world wide teams etc.

Knowledge is most common return on investment expected from a job. Developer choose job according to what they want to learn and they leave when they don’t find learning.

Our personal lives also play an important role in career decisions, sometimes we need more money and that’s OK, we should pursue that. Sometime we need more stability and security according to specific condition in personal lives (new family).

It’s not right and wrong but some of the stuff worth keeping in mind:

• Knowledge is forever
• Money, Stability and Security are not.

We always carries knowledge and experience and try to be better Crafts person, finding jobs that can pay better, and great learning helps.

Autonomy, Mastery, and Purpose

• Autonomy: It is when we are in control of what we do, how we do it, and when we do it. That should always be the case in a true Agile context.
• Mastery: It is when we are constantly learning and evolving - becoming better professional and better human beings.
• Purpose: It is when we feel that our job is important and we are contributing to make things better - instead of just doing what we are told without understanding why.

We want to assume that money is off the table and that is important. Software Craftsmen always choose jobs where they have autonomy, mastery and purpose.

According to Author, Autonomy and Mastery is non-negotiable. He will choose or leave job based on Autonomy and Mastery.

Purpose is not always as clear-cut though. Whatever we’re building we should also think about How user will going to use it. How can We make easy & beneficial for them.

Career Inside Companies

It’s always exciting to start new jobs when we choose them carefully. From the outside, every companies looked great. Our careers will always be more important than any specific job or company.

Our careers are like long staircases and our jobs are the steps. But they are not even steps.

If We’re working for a company where we have autonomy, mastery and purpose and the job is aligned with our own career aspirations, then pursuing a career inside that company is the right thing to do.

Generally, people focusing more on promotion and bonuses instead of becoming better professionals. They follow rules and orders given to them instead of thinking to make it better. They start focusing their own game instead of giving honest opinion and thinking about product. Ultimately they pray for country not to go through another recession.

Incompetent people are scared to lose their jobs when they haven’t focused on building skill and becoming better professionals. Software Craftsmen are never scared to loose their jobs. For them, a career inside a company is only viable if it is aligned with their own career aspirations. Software Craftsmen knows that their careers are long roads, where the journey is far more important than reaching the end of the line.

9. Recruitment

This Chapter is all about attracting Software Craftsmen to our organizations and how to do proactive recruitment.

An Ordinary Job Description

Having proper Job Description emphasized on requirements and need of developer.

When Job Description includes we want candidate with strong Java skill with concurrency, multi-threading expertise, strong academic background, Solaris, Linux and all those fancy stuff.

They have far bigger problems in their projects, processes, and culture, and that’s what they are really trying to fix.

With this problem, Developer has previous experience working with investment bank can check all the mentioned requirements, May be possible now knowing how to do better at what they do.

At the same time banks complaining about better people, they want to be more efficient, they want to deliver quality software.

What they don’t really understand is hiring process, they have to change it.

They will need to change how they attract great developers, starting with their job specifications.

Hiring only technical people with no other culture skill won’t help because ultimately every skill helps in the job.

If you’re failing to express company’s value and the attitude it expects from each candidate. Hiring people based on only technical knowledge will not help to drive technical and cultural changes.

There is general perception that recruitment process take too long and companies need to take 10-30 interviews to hire 1 candidate. That’s problem from interviewer side that they aren’t able to define what it means to be a good developer.

Author often visits different teams in different country and main agenda for doing this is to analyze and work closely with teams. Manager who are responsible for these teams often ask Author some questions like “How bad they are?”. Who are the developers that doesn’t fit and work as expected. Author never take any names. He mentioned overall situations instead of taking names. He said, This is not fault of developer but it’s hiring manager who is not able to take good developer.

If Author takes name of developer they will get fired and company will hire other developers. While author was also developer they don’t wanted to betray with anyone. Regardless of how good or bad they are, they didn’t magically appear here. They were hired.

The identity and culture of an organization are defined by its people and not by emails sent by the chief executive officer (CEO). Delegating recruitment to HR, recruitment agencies, or vendors means delegating the identity and culture of your organization to people and companies that don’t necessarily understand or care about it.

Too Busy to Interview

The biggest mistake of Interviewer make is saying “We can’t spend too much time interviewing people”. If you can’t allocate enough time to interview, you can’t really be serious about building a great team.

Because the vast majority of business rely heavily on software, developers play a big part in the success or failure of business.

Since hiring great developer is key, the quality of the interviewers is extremely important.

If Interviewer has mindset that they can’t evaluate a person who has same level as interviewer or above. They try to make excuses.

Their mindset should be I can work with people with same level or above to be good as something.

We must have solid criteria to filter out candidates, because interviewing 100 developers to hire four or five is not viable and wasting too much efforts.

No Job Descriptions

Traditional skills and experience-based job descriptions “are anti-talent and anti-diversity, aside from being terrible predictors of future success.”

• Absolute numbers: Defining candidate needs five years of experience in Java or certain degree required, doesn’t make sense. Having Five years of experience is different than having one year experience five times.
• Keyword matching: It’s not good idea to match exact keywords in resume, HR department doesn’t understand importance of mentioned skills.
• Listing technologies: Talented developers may not send their resumes because they may not have experience with all the technologies listed. If it is badly necessary to list technologies then showing them at broader level helps.
• Wrong culture fit criteria: Companies fail to state their values, expected attitude and responsibilities in their job descriptions. It should be described in a way that people can check mark it.
• Listing the wrong requirements: Listing the responsibilities required for a job instead of skills, technologies, year of experience, industry background and academic requirements.
• Wrong filters: Top developers do not apply for experienced-based job descriptions. They are usually more selective when choosing where they want to work. companies culture and type of responsibilities are more important than specific technology.
• No internal promotions: Normally people get promoted into bigger jobs because of their achievements, leadership and team skill instead of having 5 years of experience with Java.

What if a Job Description is needed?

If Job Description is needed, the focus should be on detailing the expected attitude and responsibility, types of projects, technologies used(not required) and values and culture of the company.

Let’s compare Job Descriptions

Job Description 1

Here they mentioned that they want candidate with strong Java Skill (5+ YOE) along with J2EE, SQL Skill (3+ YOE) and some other skills like Agile Methodologies(including TDD, JUnit etc.), Along with this description they mentioned some essential skills and beneficial skills but not essential.

They also mentioned, There will be ample opportunities for the successful Java candidate to quickly expand on their baking and funds management experience, with plenty of business exposure.

Review (Job Description 1)

Here They mixed up Agile environment with TDD and JUnit. They mentioned, J2EE instead of JEE, does that mean they are using an old version of Java Enterprise Edition. They don’t really care about Agile or Extreme Programming practices.

At the end of Description they mentioned about opportunity to learn and promoted to management domain of finance.

Job Description 2

This Job Description mentioned brief intro about the company first and then little bit about you. It also mentioned small paragraph regarding TDD such as “We’re strong advocate of TDD and we take it closely, you should be having prior experience working with TDD.”

They mentioned about the Role that How you’re going to work with teams, How company conducts learning sessions, community events and conferences.

They mentioned about Technologies they use and there is no hard bound to use specific technology. They also advocating Open Source a lot.

Review (Job Description 2)

This Job Description attract passionate and talented developers. It clearly state what they do, their values and they expect from any developer joining their organization.

It also denotes that TDD, BDD, Refactoring, Pair Programming, CI/CD take precedence over specific technology.

Job Description also clearly states learning and growing opportunities with attending conferences, community events and learning sessions.

This Job Description was written by great and passionate developers and not by HR. and They proved that they understand how great developer feel when they wrote: “For you it’s more than a job.”

A Job Is Not Just a Job

For great developers, their job is not just a job, It’s also their hobby and their passion. Companies that think in the same way great developers think, They can provide better environment where they can shine and have loads of fun.

Recommendations

Recommendations should be encouraged but not financially rewarded otherwise it would leads to other direction. Good developers want to work with good developers hence They see the recommendations system as an opportunity to bring great developer to learn and grow professionally.

Software Craftsmen understand that by recommending other good developer who also align with Software Craftsmen.

Community Involvement

The best way for companies to hire talented developers is to be in contact with wider community.

A CTO of a company represented Testing framework of company in a conference and due to that they got…

• Exposure to great developers: Many were hired directly, save time, money and efforts.
• Opportunity for their developer to learn for free: Many of them attended hands-on-coding sessions.
• Free technical advice: Their developer have the opportunity to talk to other developers.
• Cheap Investment: It takes just a few pizzas and their office space once or twice a month.

While people used to meet on regular basis, it is easy for both developer and companies to identify opportunities and work together.

It was great source of knowledge sharing, partnership, employee agreements, networking and what not.

Defining Effective Filtering Criteria

Relying on recommendations and community involvement is not always enough. We need traditional methods like Job Description and boards.

Large Organizations have to many Resumes and advertising a job position. It is totally impossible to interview each candidate. When Recruiter or HR in charge of the filtering, will usually do it by matching keywords and some random criteria. But when done by Hiring Managers they analyze the candidate’s previous experience, companies the candidates worked for and size of company, role etc.

Once author was recruiting for an investment bank. They were looking for experience developer to join their London team. Agency send him 50 resumes. It was not possible to interview lots of people.

Author started thinking about the culture they were trying to create. They wanted passionate software craftsmen. Passion was the most important criterion compared technical skills and programming language. They want people who can constantly learn, grow, share their learning with others and active in their communities.

Author send all resumes back to Agency and asked to filter out some developer who are good & talented developers. Author also shared keyword to match in terms of finding talented developers. The keyword was “Passion”.

Q: What does it mean by good developer?

This is totally context dependent. Different teams, with different cultures, developing different applications, will have different views on what a good developer means.

It is all depends on what we value the most in a candidate, in Author’s case it was passion. It’s not common in Resumes, From that point they started looking for…

• GitHub Account
• Blog
• Open Source Contributions
• Technical communities and user groups with which they were active
• Summary of pet projects (README)
• Twitter Account
• List of Favorite technical books
• Conferences where they either gave talks or attended.

It may possible that some great developers might not have things described above, the alternate solutions is to take interview for all candidates.

Proactive Recruitment

When Author along with some people started Codurance, One of their first client asked them for a very unusual service to interview 70 developers where they wanted to hire junior, senior, architects, permanent employees, contractors and so on. They also need business analysts, DevOps and testers.

They needed to make sure they would get talented developers to join the company because the majority of these developers would work directly with their clients, developing bespoke software.

Author’s team managed to select some great developers for them. and they learned a big lesson: you should never allow your company to be in that situations. Recruiting when you are desperate will make you bring the wrong people to your organization and, although you may think that at least you were able to place these developers in projects, at some point these projects are going to end.

Finding great developers take times and more likely when you desperately needed you won’t find it that quickly.

They straight away mentioned that we’re not going to hire candidates directly. We will have process to pass in order to filter great developers.

10. Interviewing Software Craftsmen

A good company needs great people, and great people want to work for a good company.

A Business Negotiation

During an interview, It is important to understand that we are not begging for a job. We’re doing business negotiation.

Before signing any contract we need to analyze and measure the risks and rewards of that negotiation.

Every Software Craftsmen has a reputation and anything that can damage that reputation must be considered as risk.

It could be may be work as factory workers, saying no in technical decisions, coding against documentations, no contact with users and stockholders.

On the other hand, if project is in trouble but developers have total autonomy to do whatever they can do the best to save project, working in close collaboration with the business, then this project can be a great opportunities for a craftsmen.

A successful service provider is the one who understand that sometimes it’s better to refuse a deal rather than having bad deal and that is a good partnership.

Identifying Productive Partnerships

Companies and developers are looking for the same thing: a productive partnership.

A Hiring Company’s Perspective

Company expects you to ask question and get interested in job role you’re interviewing for.

If candidate is not asking question that means He is just looking for a job, regardless of which one. but If candidate is asking lots of question that means he really cares about his career and finding the right company.

Having favor candidates who ask questions, It doesn’t mean they are better than the ones who don’t ask questions but at least it shows they care enough about being in a place they will enjoy.

Here are some of the things we should pay attention to:

• How enthusiastic and passionate the candidates are?
• In Technology, their previous projects and jobs and their own achievements
• How they describe their failure?
• Do they take any responsibility for thing that went wrong or do they just blame others?
• Have they done anything in previous job to improve the things they were complaining about?
• What sort of environment are the candidate looking for?
• Can we match their expectations?

We also need to make sure not only hiring but also keeping them after they have been hired. It’s important that the candidates know what to expect before starting the job.

Regardless of how we conduct interviews, when hiring talent, we should be looking for passion, ability to do the work well, and cultural fit.

A Candidate’s Perspective

For developers they must consider interviews as an opportunity to understand more about the company.

Interviewer should be developer who will work with the candidates instead of managers, leads and all other people.

Single interview process states that company is in hurry and can not take the time to hire the right people. Multi-phase interview process usually means that the company is more interested in analyzing different aspects of the candidate’s profile.

Questions asked in interview clearly states that what interviewer value the most and what can we expect when we join the team.

It’s important to observe how the interviewer will react and respond to this question.

If interviewer asked predefined question from any paper that means Interviewer is not willing to explore new ideas and engage in a debate.

Judging developer with exact answer like APIs, Tools, Technologies is the wrong thing to do. Having a open conversation about real-world and concrete scenarios, exploring different approaches and solutions, and of course writing code together, are the best ways to determine a candidate’s experience.

Author shared a story where interviewer had a printed spreadsheet with all questions and expected answer written. While taking interview they were marking check in a cell and that way they were identifying that is candidate passionate about their profession.

Now, You may validate that candidate knows few Java APIs and frameworks, but you won’t have any idea to understand weather is he writing well crafted code.

Good Interviews

A good interview is like a good and informal chat between passionate developers.

When author was giving interview in one of investment bank company, interviewer said He has read some blogs written by author, some point He don’t agree with and wanted to discuss the same thing. Discussion went for more than a hour. The most important, the things that none of them had ever though about before.

It was the first round and author made his mind to work with that company, especially the person who was interviewing them.

The point to be noted here is instead of discussing on topics based on experience or reading few articles or googling before the interviews won’t be enough to prepare a candidate for an open conversation like that.

The Right Focus

At company side we must analyze what we want to change, improve or adopt in new people hired.

If we value Test-Driven Development (TDD), Clean Code, Refactoring, Pair Programming and Agile methodologies, they should be part of our interview process.

Don’t waste precious interview time talking about things that are not relevant. Focus on What is important and more valuable to the company.

Mind-Mapping a Conversation

One technique that the Author find very useful is when conduction interviews, He takes few pieces of paper and a pen and ask very open questions such as What is well-crafted software for you?

Generally answer of that question will be list of things like maintainability, testability, readability, performs well, satisfies requirements and so on.

Now It opens lots of possibility to ask question from what candidate mentioned. You can always go back like “We talked about readability but you also mentioned testability, could you expand on that?”.

If conversation doesn’t follow your way, you can ask more specific question like “What do you think about TDD?”, That will leads to another interesting conversation.

Pair-Programming Interview

It’s huge mistake to hire a developer without seeing their coding. No technical interview is a replacement for a good pair-programming session.

This Pair-Programming clearly shows

• How quickly developer navigate to which tests to write - Shows Experience
• Familiarity with Tools, IDEs, language, testing, shortcuts etc.
• Choice of names for classes, methods, attributes
• How clean and expression the code is
• How the developer reacts when interviewer makes suggestions or comments
• Their though process
• How are they solving problems

A common approach is to choose one of the various katas publicly available or to create our own katas.

Another approach is to take and existing code (badly written and without test). Ask candidate to write test and make it better. It’s important to have realistic expectations when conducting pair-programming interviews.

It’s quite possible that different languages have different testing/mocking techniques and candidate might stuck in between but important thing to notice is how candidate reacts to this situation. The expected reaction would be to have the candidate asking for help.

Pair programming means pair programming and not standing over someone’s shoulder and applying unnecessary pressure.

Author interviewed an experienced candidate, Author was using Eclipse and Mockito. Candidate was more interested with Intellij and JMock. But his mindset was to learn something new. Within sometime he gave try to Eclipse and Mockito and notes shortcuts in some paper and got really good at it in some time. He showed passion when He became irritated because he didn’t know the shortcuts. He showed he could learn new framework really quickly. He was conformable and humbled in asking question.

Bring Your Own Computer

Asking candidate to bring their own computer shows his expertise in their own favorite tools.

An interesting exercise is to ask the candidate to clone a project from GitHub. It shows familiarity with Git, is it installed in their system? Which tools does they prefer and How quickly they navigate to the system.

We can ensure How efficient do they use their system? and How they interact with IDE, OS, Terminal and so much more.

Tailor-Made Interviews

Before interviewing any candidate, We should ask our selves:

• What are our values?
• What sort of attitude do we expect from our colleagues?
• What are the essential skills for the role offered?

Answer to this question defines our acceptance criteria, we must use to hire someone.

Author wanted to join a UK based company and He was interested in that company.

When Interviewer process got started there were 2 phase, Online test and Interview with project lead. They noticed…

• Bad way (online test) to being with interview
• Not giving chance to developers to take interview with whom author will work
• Irrelevant question (old horrible) that nobody is using at that time

Acceptance criteria was to have next round if they score 90% or more. Author scored 87% and got the response as We will reach out to you. Author made decision to not continue with that company.

The pre-selection process is extremely important. That’s where you filter candidates according to your core values.

Taking a Punt

Author interviewed a candidate in his early twenties. He was looking at the CV and it was quite boring. There is no mentioned of TDD or Agile (which was quite common in CVs).

Author would not usually pay much attention to this sort of CVs but he saw one line that made him curious “He had been a member of a Linux user group since he was 16 years old.”

Author invited him for an interview and get to know that in organization candidate was working TDD, Agile and Extreme Programming were not allowed.

Candidate was trying out TDD and all that in his pet projects. Author asked how many pet projects do you have, He said five.

Then discussion went on pet projects, Author found good skill on adapting new technology and liked his working style. Although He wasn’t that good with TDD skills.

He became one of the best engineer in that company. Moral of the story We should look for talent, attitude, passion and potential and not knowledge of specific technology.

Hiring for an Existing Team vs Hiring for a New Team

When hiring for existing team, We should look for passion, attitude, potential and solid foundation on Software Engineering along with TDD, Pair Programming, Extreme Programming practices. Specific technology can be at second level of priority because If candidate has solid foundation They can learn any specific technology in no time.

When hiring for new team member for new team, We should look for, besides the passion and good software development foundation, we should look for experienced developers with good track record of delivering projects. Dealing with client bureaucracy, business pressure, production issues and stakeholder’s management.

They must have some experience which can’t be gain though pet projects, They must have deployed medium to large projects on production environment. They must have broad knowledge instead of knowledge of specific technology. They should be knowing build tools, databases, scripting, virtual machines and whatever needed for a project.

Pre-Interview Coding Exercises

Asking candidates to submit some code before the face-to-face interview is a great way to pre-select candidates.

Give some time to solve the problem, so that candidates can give their best and write well-crafted code.

Let the candidate choose the language and tools. All we are caring about is if the candidate can code well, regardless of the language.

Looking at submitted code is a far better way to filter candidates than looking at CVs or conducting phone interviews.

Everyone Should Know How to Interview

Interview techniques are a skill we should master, both as interviewers and as candidates.

A strong team is a team where each developer can conduct interviews, making sure he or she will find the talent the team expects.

Experienced developers should always take less-experienced developers to the interviews with them.

Pair interviewing and rotating interviewers is a good way to keep everyone involved.

Developers Must Interview Developers

Sometimes, Frustrated developers were in companies where they could not choose their own teammates.

Good developers don’t hire bad developers. They will try to find developers who are even better than they are; they know how important it is to have a great team—not just for the benefit of the company but for their own benefit as well.

It’s important that developers are taking interview of developers. That way it’s easy to have great team spirit.

11. Interview Anti-Patterns

Paying attention to every detail during the selection process is one of the best ways to get insights into the culture and values of the hiring company.

Talented and Experienced developers looks for autonomy, mastery and purpose and top of that it’s clear for them what kind of client I want to work for and environment too. They make decision of accepting offer based on who are interviewing them.

Don’t Be a Smart-Ass Interviewer

Don’t try to make yourself smarter and better than the candidate. Don’t intimidate the candidate by putting her in a touch situation just for your pleasure.

While recruiting for talent, we should be looking for a partner, a person who can join your team and help you to be better, and not a submissive developer who just follow your orders blindly.

Just be honest and humble. Treat candidates like fellow professional developers. Most importantly listen to the candidate and keep your mind open. you may actually learn a few things.

Don’t Use Brainteasers

Avoid asking stupid questions that are totally unrelated to the job (Classic Aptitude questions) such as How many red ball can be fit in to square box.

The ability to answer these stupid brainteasers has nothing to do with writing well-crafted code, being a good team player, or having a professional attitude.

Don’t Ask Questions to Which You Don’t Know the Answers

Simply, Don’t ask any question that you don’t know the answer. Googling for answer and asking that question doesn’t make any sense.

Don’ try to trick the candidate with confusing or misleading questions.

Don’t Try to Make the Candidate Look Like a Fool

Author interviewed by a telecom company, they were excited because author had some previous experience working with telecom company.

There were two co-interviewer taking interview, project lead and lead architect. Interview was going good. Project lead was asking good question and good intention. Author understood that he can work well with project lead.

Then, Lead Architect started asking question regarding architecture design for previous company, Author stood up and explain high level architecture on white board. Lead Architect said it’s very simple architecture. Author understood that it’s not gonna be good partnership with him. He take some time and said, “Thank you, I will take this as great compliment. I’m glad we never needed anything more complex than that. It’s serving 20 million users in 3 different country.”

He thanked both interviewer for opportunity and left.

Don’t Block the Internet

Sometimes, Interviewers don’t allow candidates to use internet but Is it possible for interviewers to work without internet?

It’s an essential skill for any software developer to search and solve problems. Removing Internet access just doesn’t make sense.

If candidate is able to search and find answer, interviewer must change the way of asking questions.

Don’t Code on a Piece of Paper

According to Author asking to write code on a piece of paper is a very stupid idea when it comes to interviewing developers.

There is a difference between being a teacher in high school asking students to produce algorithms in pseudo cod and hiring a professional software developer.

When hiring professionals, we should look for developers who master their tools and techniques and who can produce well-crafted code through testing and refactoring.

Don’t Use Algorithms

It’s common nowadays where interviewers are asking problem solving exercises, the motive behind that is “They want to test ability of solving problems”.

The reality is they can test the same thing by asking exercises that are closely related to the their projects.

Algorithms are procedural and better implemented in a functional style. We don’t create classes or model the business domain when implementing an algorithm.

The real essence is What we need in work, we should ask the same thing in interview.

If product/application is all about algorithms, then of course, we should definitely test for that.

Don’t Conduct Phone Interviews

Phone interviews are only needed when the pre-selection process is poor.

It shows the interviewer is usually in rush to ask the questions she need to ask in order to decide if she will or will invite the candidate for a longer interview.

It’s challenging for non-native speaker, may be they can’t express well without body language, paper, whiteboard.

It is good only when it’s the only option. Suppose candidates who are located in different countries and always favor a face-to-face interview.

12. The Cost of Low Morale

Low morale can be one of the main reason for a software failure.

The Agile Handover: Low Morale

After the transformation of the agile, companies realized that their software delivering capability is still very poor. This realization is call the Agile handover.

A common problem we find in all these companies is low morale. It’s common to see people blaming other colleagues, manages and environment.

Managers do talks about 5 years plan but the reality is nobody really know what needs to be done and still we have loads of people that are not directly involved with the project.

Different teams asking for urgent features, those are quite often conflicting with each other. Normally requirements are too busy such that no one is ready to explain them in detail.

Even team suggested a better way of working but nobody listened to that.

Adopting Agile should be…

• Synonymous with empowering people
• Embracing change
• Improving collaboration
• Understanding the value of each piece of work and knowing why we are doing things
• Synonymous with doing things right
• Improving communication
• Delivering value to customers
• Shortening the feedback loop
• Working effectively as team

A true agile organization can easily provide what knowledge workers need the most of enjoying their jobs: autonomy, mastery and purpose.

It’s the general case where employees are not enjoying their job. It is common to see unhappy developers working like zombies, just waiting for clock to hit five o’clock. The question is here is “Are we really motivated and enjoying out jobs?”.

Although, Agile transformation really made it’s impact from building software and delivering it. Agile coaches had very little success improving developer’s technical skill; very few Agile coaches actually sit down with developers and write code. Due to that Developers quite quickly learned not to listen to these coaches that’s because they don’t know the impact when they talks about TDD and Extreme Practices.

The Cost of Employing 9-to-5 Developers

When asking passionate developer about what to do with 9-to-5 developers, the first thing that comes to their minds is fire them all.

Lack of passion is not what really bothers passionate developers; what frustrates them is to be held back by other developers when they are trying to improve their application and the way they work.

Author worked for an international media company and responsible for developing a new placement system for a 14-year-old internal system.

Everything was going down due to unskilled developers, application was supported by them.

There was a major issue between teams/developers, Author noticed that people rarely have interaction with other developers/team members.

In standup, not all members join it actively and there was a notion of working for 2 weeks and not caring about iteration, delivery and prioritization.

Situation was like “this feature here will probably take around six weeks to be developed. I’ll let you guys know when it is done”, some developers used to say.

Author tried couple of things to make situation better, He organized dinner, drinks not only that, We tried paring with people and discussing about TDD and other new stuff. Turns out no one was interested in that, Developers say “Sorry Man! I’m not interested in rushing the task, I have life and I don’t want to stress out, I don’t really care and client either”.

Author was the only one who was writing tests, assuming that some day people will enjoy working with this. It went other way around, “We told you that it’s waste of time” they say.

Author was increasing frustration along the time and decided to leave the company OR change the team.

The Software took 7 years and costed 10 million pound at the end. It could have done in 18 to 24 months and 2 million pound.

Just with passionate developers and good business people, company could have same 5 years and 8 million pound and could have invested this 5 years in innovation and research.

In projects like this, it is impossible for a single developer to change the world.

Constrained by Lack of Motivation

Almost every company has problems, Every single employee without much efforts, could easily come up with a big list of thing they wished were better.

If employees know what need s to be changed and how things could be improved, Why don’t they do anything about it? Here are common reasons

• They don’t feel they are empowered to do it
• They don’t want to be the ones pushing it
• Nah! too much hassle
• They don’t believe that things could be changed
• They don’t care, It’s just a job

The reason why many companies fail when trying to improve the way they work is low motivation. There is no way we can change organization when people in the company aren’t motivated and don’t care about their jobs.

Always ensure that

• Are they motivated to do a good job?
• Do they really care about improving the way they work?
• Are they constantly getting better?
• Do they even believe in or like what the company does?

Injecting Passion

Embedding Software Craftsmen in a team, Either hiring them permanently or bringing external craftsmen for a period of time, is the most efficient way to motivate existing developers. They are on a mission

• To make things better
• Deliver value to their clients
• Inspire people around them
• They aren’t afraid to lead the way and drive changes

A Software Craftsman can sit down and pair with developers, sharing their knowledge, experience and passion.

How Author transformed Investment Bank Company?

One of the first thing they did, They hired a few craftsmen to join them. The advantage of bringing a few more craftsmen to the team was that they became out allies not only to fix technical problems but also to inject passion and bring innovations.

They started asking “has anyone learned anything since out last stand-up meeting?”. Eventually started sharing blog, videos and book links in group.

Things like that completely changed our environment. Developers were excited about technology again and were keen to get better.

What before was a boring department in a large organization was now a cool group of people working very efficiently, always striving to get better.

13. Culture of Learning

It is really important to create a culture of learning in companies, here are some things that is used in large to small companies.

Wrong Motivation

Author was assigned to work on a project by a investment bank hired consultancy firm. They wanted to retrofit unit test to their code base.

While Author was on bench, they can’t really say no to them. They haven’t asked developer to work from their office. Usually companies never allows their code to be accessed from outside their premises.

For a few months some colleagues and Author wrote unit test for the existing code without even speaking to any of the developer who wrote it. The client was very clear: “You just need to write the test, Your target is to bring the test coverage up to 70 percent, you have to keep maintaining this mark”.

There were some weird behavior of code, Team wanted to talk to developers who wrote that code and they seems to be busy and not wanted to talk to them.

Somehow, Author and his team able to achieve 70% test coverage, and after that deal of that project got closed.

It was just to have bonus from other end and for that to fulfill they at least needed 70% tests coverage and they outsource for the same.

Author would have easily said no and skipped it for it. but now it’s even more dangerous, some people would trust those tests. Bad tests are worst then no tests at all.

We will never change an organization by forcing people to adopt a new process or different practices. Instead, we should create a culture of learning, where people can find their own motivation to make things better.

Creating a Culture of Learning

Creating a culture of learning is one of the most efficient ways of injecting passion into a company.

When senior developers are not motivated, it leads to junior developer to not being excited about the software development.

These young developers, as they join the industry, have to deal with crap and unnecessarily complex code produced by seniors, and at the end junior developers find PowerPoint presentation and Excel more attractive then writing code.

On the other hand, if the same junior developer had been brought up in an environment where their seniors were always trying to find ways to get better at what they do, keep learning new stuff, it will truly aspiring to become software craftsmen.

The better the developers are, the more innovative and agile the company can be.

If the company becomes a place where developers are happy, many other good developers will be attracted to it.

Let’s explore some of the things developers can do to create such an environment.

Start a Book Club

Come together with your colleagues and start reading the book, see if other developers are interested in the discussion.

If no one is interested, ask the other developers what sort of book they would like to explore, choose the book and go with that.

If still no one is interested, start reading the book you want, but take the time to share what you are learning during informal conversations. May be some of the developers who initially were not interested will change their minds and join you.

Have a Tech Lunch (Brown Bag Session)

Ask your team if, once a week they would like to have lunch together while talking about technical stuff.

It is not required to have proper structure but it can help in various ways such as technologies, approaches, techniques, books or whatever else people want to share and discuss.

Let people also do short presentations if they want to. Tech lunches are very easy to setup because there is no presentation or organization needed. You just need a place and people bringing their own lunches.

Have Group Discussions (Round-tables)

Divide a wall or whiteboard in two. One side is for lightning talks; the other side is for topics to be discussed in a group. Ask participants to write down the title of the lightning talk they want to give (five minutes of lightning talk, 2 minutes of questions) or the topic they want to discuss as a group.

The basic idea is to people can propose the topic on which they would like to discuss and present in brief to raise the discussion on the same.

Other people can share their questions and thoughts on the it. and after sometime other people can have change to repeat the same.

Switch Projects for an Iteration

Within a company, it is common to have different development teams working on different applications or in different parts of the same system. After a period of time, projects fall into a routine. We rarely do previous decisions get reviewed.

Assuming that developers are constantly pairing with each other, we can solve this problem by providing an opportunity for developers to switch projects for at least a full iteration. Ultimately it can leads to positive effects:

• Validation of the decisions: The new person, after understanding the context in which the decisions were made, can confirm that it was a good decision.
• Knowledge Sharing: The new developer learns how certain problems can be solved.
• Improvements: The new developer can propose better way to solve those problem.
• Collective Learning: After discussing the current solution, people from existing team can discuss better solution collectively.

Switch Projects for a Few Hours

We can have developers working in different teams to switch team for few hours or days. Developer can organize the switch themselves.

Just go to other teams location and sit down with one of the developers and pair with them for a couple of hours.

It helps build good understanding of how other teams are working and why and how they’re utilizing the power of different technologies.

Conduct Group Code Review

Group code reviews are another very interesting way to create a culture of learning. It is a way to learn from our peers.

It’s important to have code review get it right. it means…

• Comments should never be personal.
• It doesn’t matter who wrote the code.
• Never look at the commit history during a group code review. Focus on changing the future.
• Comments should be objective and constructive, the focus is on how ti make the code better and not to say why it sucks.
• Sometimes having facilitator helps, They ensure that everyone speaks and there is no finger-pointing.
• Don’t expect to make a lot of progress, if developers want to spend a lot of time discussing a single issue, let them do it.

Have Hands-On Coding Sessions

Hands-on coding sessions are sessions where developers get together to write code.

Facilitator must know the exercise very well before the session, they can practice couple of time before the session.

Developer will pair with whom they never paired to paired rarely. Facilitator should walk around and help developers normally he or she should ask challenging questions, not give them the answer or direct suggestions.

The Facilitator should run small retrospective where every developer can share what they’ve learned new, what they’ve done.

Developers thank their pairs when the session is over.

Hands-on sessions are very helpful for injecting passion into out teams. It creates opportunity for developers to learn from each other and bring a bit of fun to the workplace.

Few things to take care while organizing this sessions…

• Don’t make it about work. The focus is to practice and learn in a safe environment.
• Allocate two hours for the session: one hour from the company’s time and one hour from the developers own personal time.
• Run the session in friendly and informal way for the very first time to encouraged to run future sessions.

Favor Technology-Agnostic Thinking

Try running technology-agnostic sessions. Although it is always easier to run technology-specific sessions, if developers are not interested in the technology they won’t come.

When running technology-agnostic sessions, developers are in control of which technologies they want to use, which will make the session more enjoyable, add few constraints such as you can’t use else statement, you can’t talk with peer, you’ve to commit code every 2 minutes.

At the end, retrospective will be more interesting and informative, each developer will talk about the challenges they had while using the technology they’ve chosen.

Start Internal Communities of Practice (CoP)

When you have few internal sessions on going, invite the developers who come more often to the session to help organize the sessions.

You just need 2 people to start a community, internal or external, then you start attracting people over the time.

You can share more about the community over lunch or coffee breaks in informal conversations.

You need to make sure that we’re not focusing on growing the community. Focus on having fun and running good sessions. The growth will come naturally.

Encourage Pet-Project Time

Pet Project means You are your own boss. You decide what feature to work on next, how you want to do it and most important, there are no deadlines.

Passionate developers love to have a playground where they can try many new ideas, technologies, techniques and approaches.

Extract the time for paring with someone on their pet project.

Engage with External Technical Communities

Look for technical communities in your town, invite your colleagues to go their meetings. See how you can contribute.

Exposing yourself and your colleagues to so many passionate and amazingly talented developers from the external communities can be a great way to motivate you all.

What if Others Don’t Want to Join In?

Different people, on different projects, in different companies, behave in different ways.

You don’t need to change every person to make the organization more effective or a better place. It leads to frustration for those leading it. Frustration leads to lack of motivation, which in turn will make us give up.

Be an Example

“I would love to do TDD but no one else in my team wants to do it.” Developer complains. This is an excuse, not the attitude of a software craftsman.

To solve this issue, one way is to inject passion into a team and help them embrace different ways of working.

Having someone who is not necessarily experienced but has enthusiasm leading the way may be what is needed to ignite a whole team.

Focus on Those Who Care

Not everyone will be moved by your enthusiasm and willingness to change. Focus on the ones who are willing to change. Pair with them, Write tests and review each other’s code.

Don’t Force

Forcing developers to attend any of the learning initiative will just make things worse.

If someone don’t want to join them, don’t just keep sending invites, let them go.

Don’t get disappointed or angry with developers who don’t want to join in. Keep your own motivation up, regardless of how many people turn up.

Don’t Try to Changer Everyone

If you’re team of 10 people and no one doing TDD or Pairing and after a month 3-4 start doing TDD, be happy about it.

You don’t need to change everyone.

Avoid Consensus Delays

Trying to reach a consensus of when and where to run the sessions, instead just say, “Everyone, Me and John will be in the meeting room every Wednesday at 12:00 PM playing with Java, you’re more than welcome to join us.”

Don’t Ask for Authorization

You don’t need authorization from your boss to learn and practice on your own time. This is true in many companies. Even during working hours if you don’t ask.

Find an empty room and have the meeting at lunchtime, early in the morning, or late in the afternoon.

Don’t Complicate

“Our office layout is not suitable for group activities, we don’t have projector, etc.” There are just complains and due to that sessions never happens.

If this is the case, go to coffee shop, and manage and focus on goal instead of complaining about other misc stuff.

Establish a Rhythm

The secret to having a healthy community, and keeping the sessions going, is to have a rhythm.

Regular meetings are also much easier to organize. Find a meeting room and schedule a recurring meeting inviting everyone.

It is not difficult to bring a culture of learning into an organization. The only thing needed is a passionate developer willing to start it. Stop finding excuses and be this developer.

14. Driving Technical Changes

How do we bring technical practices to our team? It’s easy to convince developer to adopt technical practices instead of managers.

Identifying Skepticism Patterns

The first thing Software Craftsman needs to do before trying to create culture of learning is to introduce new technical practices, tools, or processes to identify the skeptics they are facing.

Categories that skeptics of technical change tends to fall under: the Uninformed, the Heard, the Burned, the Time Crunched, the Boss and the Irrational.

The Uninformed

The main reason to not adopting certain tools or practices is lack of awareness. They don’t know the impact it brings or even is that exist or not.

This group of developers don’t read books or blogs or trying to understand what is going on outside their cubicle.

The Herd

They feels that they are not experienced enough to make certain decisions, they lack confidence and leave the decision to smarter and more-experienced developers.

This group of developers are usually followers, not leaders.

The Cynic

They like to argue and are constantly trying to prove that they are smarter than everyone else.

This group of developers think that looking smarter is more important that being smarter.

One of the reason they don’t want to adopt tools or technical practices is they don’t want to expose their own weakness.

The Burned

They tried a certain practice or tool in past and it didn’t work for them, since they haven’t had a good experience, they don’t want to try it again.

eg. following TDD, may be they found tests are too long or difficult to write.

The Time Crunched

They are always busy and never have time for anything.

This group of developers are usually very shortsighted and unable to see the real cost of things.

The only thing they see is that they don’t have time to change the way they work.

The Boss

If the boss is not a technical person, they probably won’t understand what you are talking about and will fail to see the advantages of what you are proposing.

Very few technical managers were actually great developers in the past, and even fewer were actually promoted because of their software development skills.

The Irrational

The worst type. They will swing from one premise to another as they get defeated.

Common things are “This will cause performance issues, Framework has security issues”, One after another, they will raise irrational points against the proposal and as soon as we defeat their point.

There are few more categories that author has identified.

The Indifferent

The Indifferent simply doesn’t care. Developers in this group don’t necessarily go against anyone or anything.

It leads to lousy implementation of good ideas, eg. Bad tests are worst then no test.

The Wronged

This is dangerous type. Developers in this group think the company has wronged them.

They always thinks that they are underpaid, not getting recognition they deserved, or are being unfairly treated.

They don’t like company and never miss a opportunity to badmouth it.

The Inept

They just don’t get it. They are more aware than the Uninformed by the are not able to see things clearly.

This group of developers see software development only as a job, even when they try, it is clear that this job is not for them.

The Ivory-Tower Architect

This is also worst type of skeptic for a software craftsman to deal with, they think they know it all. They are smarter than any developer.

They like to say they are responsible for every technical decision, but very rarely are they held accountable for any of them.

They don’t really product the output which is required for business. They want to be the first in every win to steal credits at the same time want to blame development team in case of any problem.

The Insecure

This group of people are worried about getting replaced or losing their status. These are usually average developers in the organization.

They fear that, their customer will realize that they are not so great. They see software craftsmen as a threat and will do whatever they can to discredit them.

The Fanboy

They are totally devoted to a single subject in a fanatic manner.

They are biased about the stuff they know and easily reject any possible alternative.

They don’t want to consider anything else because they are specialist in one particular thing.

Be Prepared

There are a few things you mus have if you really want to change things around you. The most important one is courage.

Encourage Simplicity

You idea or proposal must be simple and clear. Organize your thoughts before proposing anything. Make it very easy for people to understand.

Speak the same language

Learn how to speak their language, you’re taking with developers, managers, architect, product owners or any other person can be affected by them.

Do your homework

Make sure you understand what you’re talking about. Research, try, and practice.

Think about what question can be raised and be prepared with acceptable answer before you speak to them.

Be clear about areas you don’t know about or have very less context.

Be respectful

Don’t treat people as if they are stupid. Disrespect and aggression will immediately put people in a defensive mode.

Learn how to listen

You may have a very good idea of how things should be done, but make no mistake. Everyone has an opinion and sees the same problems from different angles.

Probably, There are many things you’re not aware of. Listen and digest what everyone has to say about particular idea.

Where Do We Start?

After a short period of time in a new project or organization, ideas for improvement start popping out. Eventually, it’s hard to push our ideas forward. So where do we start?

Establish Trust

We can’t change anything if people don’t trust us. Trust can be built by consistently delivering quality software.

Different people has different point of view to judge the quality of the software. Developers will say it means is code maintainable?, how we’ve named out functions, is code readable? etc.

For Delivery Manager, Quality Software means software that satisfies the requirements, has no bugs, and was delivered on time.

For Client, It may mean software that is in production, making them money, saving them money etc.

Although essential, consistently delivering quality software is not enough to built trust, You need to expose yourself. You need to be visible. You need to show your passion that you’re caring about the project.

But showing your passion is not enough either, above all, to establish trust, you need to be good, people need to feel that you can do it. They need to feel you can lead them

Gain Expertise

When proposing changes, we always tell our teams that we will be a much better place if we did the things we are proposing. Skeptics will immediately say that is too risky, it will cost more time and much money.

Before proposing anything, make sure you understand it, play with it, build something with it, talk to experts, and compare it to other alternatives.

The more you understand and teach the stuff, It will easy to understand the skeptics and change behavior of some skeptics. If in case you fails, you will have more knowledge than you had before, Which makes you a better professional.

Lead by Example

When proposing changes is about attitude and practices like TDD, nothing will help you more than the ability to lead by example.

Certain disciplines and practices take years to master it, You can’t just share few internet links to understand clean code, planning iteration, inspiring people, software design etc.

Developers may reject certain practices because they are too difficult to master or to become comfortable with. We can help developers to overcome their initial fear by sitting down and writing code with them.

Developers will feel much more comfortable adopting a practice if they know they can count on us to pair with them.

If you want your team to behave in a certain way or adopt a technology or practice, first make sure that you can do that yourself.

Choose Your Battles

It’s common thinking that If someone has power to fire and hire anybody they want without disturbing them , they can change entire organization. but that is very naive and inefficient.

While author was working for investment bank company they wanted to do the same, They wanted to make change in code here and there and rebuild entire application, fire and hire people etc. But trying to do everything at the same time wasn’t just impractical but also impossible.

One of their primary goal is to change the culture of the organization and for that they changes the recruitment process and made sure that any new member joined aligned to the culture they wanted to have.

Second Goal was to introduce TDD & Pair Programming, that took a long time to comfortable with it.

Before driving all these changes, we need to consider the impact of those changes, speak to a lot of people and prepare ourselves for the tough questions from the most varied types of skeptics.

You don’t get to change the software development process of an organization, large or small, if you don’t prepare yourself for it.

Iterate, Inspect and Adapt

One of the easiest ways to avoid big confrontations is propose gradual changes. You propose the idea and implement at small level and let your team decide if they want to adopt that idea.

We can use iteration boundary trick: Let’s try this approach for one iteration and then we revisit.

Some more skeptics arise, to target them you can say Let’s try this for one iteration, on small part of software, if we don’t like it, we will revert it.

Fear and Incompetence

Fear and incompetence are two of the culprits of bureaucracy and politics inside companies.

It can be because of organizations policy, that ill-defined architecture has to be followed which is not even designed by developer of the team.

Fear. Incompetence. The fear of losing our jobs. The incompetence to develop good solutions and convince our team to do something better. You knew that it’s wrong but you can’t really show that because He is the boss.

Only incompetent people fear losing their jobs. “If I make my boss happy, I’ll get promoted. I don’t care about the company, I care about my bonus.” This is selfish, unprofessional, and immoral.

Software craftsmen are in control of their jobs and careers. they have their ethics. they know they will never struggle to find a job in a place where they are valued.

If you want to change thing around you, don’t fear. Prepare yourself, practice, read, study and be the best you can be.

How Do I Convince My Manager?

The simple answer is you don’t. Managers want projects delivered on time, on budget, and with no bugs, and they want to make stakeholders and clients happy. Who cares if we use TDD, if we pair, or have continuous integration? Besides us, no one.

We are expected to deliver quality software. We are expected to deliver good solutions. So, when it comes to TDD, pair programming, continuous integration, or any other practice you think can help you to achieve that, just do it.

Testing a class and writing code for that class are not separate task, it should be consider as a one task.

You don’t have to point out small thing like “unit testing” on the board and asking manager to take extra hour to do that, instead you should consider coding task that include testing to work better.

How Do I Convince My team to Do TDD?

Introducing a new framework, tool, or design approach is hard.Telling other developers that they should change the way they work in order to produce better code is even harder.

Asking for help is very good way to introduce TDD without much friction. Convince enthusiastic developer to test out TDD for fun, even they oppose the idea tell them, let’s do for fun for one to two hours.

Offer them keyboard too and have them feel the essence of TDD, gave good feeling about this practices.

Introducing TDD to someone who is eager to learn it is quite easy. it can be very tricky to introduce TDD to someone who is skeptical about it.

Developers are creatures of habit and are generally very opinionated. You cannot just go there and tell them what to do.

Facing the Skeptics

Practicing in our spare time, preparing ourselves, and being able to demonstrate our technique can take us a long way when driving changes. We can easily inform the Uninformed, shepherd the Herd, convince the Cynic, understand where the Burned went wrong and reason with them, and reduce the team’s learning curve, which addresses the Time Crunched’s concerns.

Being able to communicate well and at the right level is also important. Talk in their language such as you don’t need to expose development issue to manager because they don’t care.

Ignore the Irrational. Besides a huge amount of stress, there is nothing to be gained discussing issues with Irrationals. Focus on interested people.

Make sure you include everyone in the decision-making process. Don’t impose your opinion. Your objective is to make things better, not to become the Boss or claim the credit for all the improvements.

Sharing your passion, leading by example, being honest and transparent, great confidence, and teaching what you know are the best ways to gain the trust of people around you.

The Ivory-Tower Architect

The Ivory-Tower Architect will probably be the most difficult skeptic to deal with. Architect will try to push for a big upfront design, trying to define the technology stack and general architecture even before understanding the business problems we are trying to solve. Instead Software Craftsman would consider following more of a Agile approach to software development.

Architect will just draw small boxes but won’t really understand what’s going behind the scene. Because the Ivory-Tower Architects are not part of any development team and don’t write code, they never feel the pain caused by their ill-defined architecture decisions.

Responsibility versus Accountability

Ivory-Tower Architects feel they are responsible for all the decisions and think that developers are just a bunch of coders implementing their vision.

Tower Architects become responsible for the solution while the developers are the ones who are accountable for it. They see developers as mere coders that should do whatever they are told.

Author was working with large organization, the relationship between the team and the Ivory-Tower Architect got tense, here is what happened then…

In the conversation, a software developer and an enterprise architect clash over the choice of a web framework. The architect insists that all projects must use the framework he recommends, claiming it ensures consistency and allows easier replacement of developers (people fungibility). The developer argues that the development team is in a better position to choose tools that meet the project’s needs, especially since the business requirements are still unclear. He emphasizes that their team has already set up a system for quick changes and feedback, which is helping the business move faster.

The developer challenges the architect’s authority by suggesting that if the architect wants to make all the technical decisions, he should also be accountable for any problems or delays, including explaining them to stakeholders. Faced with the possibility of being fully responsible for any project delays, the architect backs down and agrees to let the development team make decisions, as long as they document them.

In the end, the development team is allowed to choose the tools they believe are best for the project, leading to successful outcomes. The architect is eventually reassigned, and the conversation highlights the importance of aligning responsibility with accountability in technical decisions.

The Wronged

The Wronged is another very difficult type to deal with. They are not against you, they are against the company. Instead of resign they still hanging there and doing poor job.

There is nothing much we can do besides trying to make then excited again. The best thing is to treat the person well, do out best to integrate the person with the rest of the team.

Should We Really Care about All That?

Besides all the technical skills, a software craftsman is also a role model for less-experienced developers.

They are not afraid of being honest and transparent. They don’t lie and hide something to make customer happy. They take responsibility and are not afraid to fight for what is best for the project.

As a software craftsman, you cannot deliver value to your customers if you work on a dysfunctional team or environment.

Just writing well-crafted code is simply not enough to ensure client success.

15. Pragmatic Craftsmanship

There is an assumption that quality takes time. Managers and developers believe they need to choose between expensive well-crafted code that takes a long time to write or cheap average code that is delivered faster.

Quality Is Always Expected

No manager or client expects bad-quality software. No matter what they will always expect quality even if developer tell them that quality will suffer if they want to keep the costs down but they will still expect quality.

The main problem is this big and wrong assumption that cheap and average code is good enough - It could be for short term, but for mid and long term it will not work.

Client will always expect quality work because at the end they don’t care about software development stuff, for them software development is a service like any other service. Developers are expected to deliver good value for money.

You might have a choice such as within budget, but with low quality, OR over budget with high quality.

If We think from perspective of client/manager, they think even they choose tight budget and low-quality work, They will always hope for quality work. They will hop for not having problems/bugs for the service they paid for.

Busting the “Expensive and Time-Consuming Quality” Myth

Software craftsmen embrace Extreme Programming (XP) practices and Agile principles. In an project developed by software craftsmen, the client will have working software from day one.

Completing a new feature means, feature is deployed into production or a production like environment if company is not ready to release the software publicly.

Software Craftsmen masters their practices - TDD is second nature and not something that slows them down. Because every feature is test-driven, application developed by craftsmen will always be entirely covered by tests. A big suit of automated tests in a reasonably large application, when done by craftsmen, is executed in few minutes, if not seconds, making delivery of features much faster than when done without tests.

Applications developed without tests demand longer cycles of manual testing as they become bigger, making continuous deployment totally impossible.

Manager and some developers says It slows down the process while following TDD and Pair Programming, we can’t just say that due to these technical practices the pace is slower, instead we can say, Developers are slower than normal while learning any new technical practice.

When comparing experienced software craftsmen who have mastered these technical practice with normal developer, the different might not noticeable in small piece of code, but for larger project and bigger problems software craftsmen will be way faster.

Learning and mastering practices takes time and can be costly, but that doesn’t mean that the practices are bad.

Do We Need to Test-Drive Everything?

A pragmatic answer would be “no”. Some TDD Skeptics says “What if we need to hack something quickly so we can show it to potential investor or try out the market?”.

Context is more important when choosing your tools and practice.

If we ask experienced XP developers, they will have some discussions around TDD a waste of time; TDD doesn’t slow experienced developers down.

Developers who are proficient with TDD would never say that TDD was the main reason why they could not finish something in time or that they didn’t write the tests because they didn’t have time.

If you follow this practices regularly, you are more likely to achieve good speed and produce high quality in whatever you’re delivering.

Refactoring

Refactoring for the sake of refactoring is a waste of time. The Boy Scout rule says “leave the campground cleaner than you found it,” not “clean the whole campground until it is so clean that you could lick the floor.”

Refactoring the code before adding a new feature is a good idea when the impact on the code is significant. Author would refactor their code in a way to make it compliant with the “open/closed principle” (OCP) first, and then add the new feature.

Improving your system with small but constant refactoring, justified by necessary changes to the system, is a good and more pragmatic way to improve an application.

The “One Way” of Developing Software

The main mission of the Software Craftsmanship movement is to raise the bar of software development.

For developer starting on their journey, they should make good judgement, we recommend that they follow the practices we advocate, and as they move forward they should find better ways of doing things, exploring alternatives, trying them in real projects, and sharing experiences with the rest of community.

Good practices and processes are good until we find better ones to replace them.

As craftsmen, we should not believe that TDD and all the XP practices are the best practices we will ever have. At this time, they are the practices we use and advocate but that doesn’t mean we should stop looking for ways to improve.

Don’t rush to call people unprofessional just because they don’t use certain practices. Ask them what practices they use instead and then compare the benefits their practices have over the practices you use.

Helping the Business

It’s common to be on a project where the business doesn’t really know what they want. Any Agile coach would say that in order help, developers should engage in conversations with the business, ask questions, and propose solutions.

When the business is still trying to figure out what they want, and the only things they have in mind are ever-changing, half-baked ideas, the best way to help is to put something in front of them as soon as possible. We should be able to change the code almost as fast as they change their minds, giving the business an opportunity to visualize their ideas and also to get feedback from the people who will use the application.

A Simple and Quick Solution

The team was building a web application and used mockups to agree on how it should work with the business. But these mockups didn’t give a real feel of how the application would work, especially for more interactive features. The business wanted to actually use the application in a safe environment, show it to others, and release new versions every month.

Some features were easy to build, but others were more complicated because of rules and technical requirements. While it would take time to fully build everything, the business wanted quick feedback on how the entire system worked, not just individual parts.

To move faster, the team decided to build a version where users could see all the pages, but not change any data. The data would be stored temporarily in memory, without saving it permanently. This helped them quickly show how the application would work, without dealing with complex data management. Some pages allowed limited changes to the data, but those changes wouldn’t be saved.

Even though they were building quickly, the team still used test-driven development (TDD) to keep the code quality high. The simple design made it easy to make changes as the business gave feedback. Over a year, they had very few bugs in testing or production, and TDD helped them release new versions quickly and confidently.

The main takeaway is that the ability to handle frequent changes without breaking the software was key. TDD, continuous integration, and pair programming helped the team work fast and maintain quality, allowing them to deliver value to the business efficiently.

Software Projects Are Not about Us

As professionals, we need to understand that a software project is not about us and our egos. Even if the project is about you, you should not have mindset of I-know-what-I’m-doing-and-I-don’t-need-to-write-tests.

It’s equally important to think, who will be handling the project when we leave. If the value we add to a project is conditional to our continuous involvement in the project, it’s not value. It’s a point of failure.

Great Versus Mediocre

Passionate developers love writing code. They enjoy creating complex solutions in order to keep themselves interested in the job.

Back in the 1990s, creating complex and cryptic code was a sign of seniority. You were considered senior when you could write code that no one else could understand.

Great developers write simple code that satisfies the business requirements, and less-experienced developers have no problem understanding it.

Well-crafted code is simple, small, testable, easy to understand, and most important, does the job. Code is the main source of bugs and pain. The less we write it, the better.

Four Rules of Simple Design

Before thinking about architecture, design patterns, generic solution, or anything else, as a rule, a software craftsman will always try to write code that satisfies the “Four Rules of Simple Design” as defined by Kent Back:

1. Pass all tests
2. Clear, Expressive and Consistent
3. Duplicates no behavior or configuration
4. Minimal methods, classes and modules

Four Rules by J.B. Rainsberger

1. Passes all tests
2. Minimizes duplication
3. Maximizes clarity
4. Has few elements

As we follow TDD, rule no 1 is obvious, hence it can be ignored, We would naturally have fewer elements, hence the fourth rule becomes irrelevant. Now we have 2 rules in mind.

1. Minimizes duplication
2. Maximize clarity

We would always favor clarity over duplication, so as a guideline. in order to achieve a simple design, we focus first on good names, nice abstractions that represent business concepts. Then focus on removing duplication.

When removing duplication, new structure will emerge, again we cycle through maximize clarity and then again remove duplication.

Combined with the knowledge of Domain-Driven Design and the SOLID principles, this approach is normally enough to achieve well-crafted code without polluting the code with loads of design and architectural patterns.

Design Patterns

Look at all the legacy code we see out there today. It is far easier to identify the design patterns used by the developers than the actual business features they were trying to satisfy. Generic code is a great thing, but it doesn’t come for free. The more generic the code is, the more complex it becomes.

The Ivory-Tower Architects thinks, because of TDD we went from writing generic and future-proof code to writing specific code that satisfied our immediate need.

We will pay big price in the future when it comes time to maintain.

Refactoring to Patterns

Ivory-Tower Architects are wrong to advocate for Big Design Up Front (BDUF), but correct in saying we shouldn’t discard decades of design knowledge. Proficient TDDers don’t start with design patterns. Instead, they write tests based on business requirements and just enough code to satisfy them, using the refactoring phase to simplify and improve the code.

When requirements change, such as adding contractor payments to an existing salary system, refactoring is used to introduce necessary abstractions. This “just-in-time” design allows the code to evolve without unnecessary complexity. However, introducing abstractions prematurely adds needless complexity and confusion. Pragmatically, abstractions should only be added when truly necessary, helping keep the system simpler and easier to maintain.

Design patterns are useful, but should only be applied when needed. Instead of forcing patterns early, refactor the code when necessary and introduce patterns naturally if the solution aligns with one. Specific code is simpler than generic code, and generic solutions should only be introduced when justified by the problem.

In the early days, many developers, including the author, focused on architecture and patterns before understanding the problem. This highlights the immaturity of focusing on patterns first rather than addressing business needs.

Craftsmanship and Pragmatism

Craftsmanship without pragmatism is not craftsmanship. A craftsman’s primary focus is customer satisfaction. Besides quality, time and cost are part of this satisfaction. Code cannot be considered well-crafted code if it doesn’t provide value.

Regardless of how big or complex the project is, a craftsman will always produce quality code. Clean and well-crafted code is important—it gives us the ability to quickly and safely make changes according to the business needs. One of the best ways we have to help the business to achieve their goals is to be able to change the code almost as quickly as they change their minds.

16. A Career As a Software Craftsman

Being a Craftsman

Passion. That summarizes it all. Software craftsmen are passionate about software development and their profession.

Software craftsmen are humble, always ready to learn from more-experienced developers, and eager to help the less experienced.

We want to excel at what we are doing, either it’s wiring code or delivering business value.

It’s a constant search for better and more efficient ways to deliver value through software.

Being a craftsman means to be curious and experiment with new things. It is not to be dogmatic about tools, languages or frameworks.

A craftsman is missed for the right reasons: insightful contributions, enthusiasm, knowledge, and, most important, being a great colleague.

Honesty and Courage

Honesty and courage are essential qualities of a software craftsman. Saying no if requirements are unrealistic and not going to work. Point the client in case of bad decision.

However, simply saying “no” is also not a craftsman’s attitude. A “no” should always be followed by a “but.” “This will not work, but maybe we could try this other thing instead.”

The career of a craftsman is built on honesty and courage. A craftsman never hides anything from customers. Craftsmen and customers are in a partnership, where honesty, courage, and full transparency are key.

Career Progression

Author was working with few teams in Eastern Europe, Their mission was to introduce Extreme Programming (XP) practices, helping developer to write better code and inject passion in the team.

Once, author asked a team, “What you want to be in next few years?”, after 2 minutes of silence, someone said “I want to be an architect”, other said “i want to be a manager”, another said “I want to be a head of product”. Author asked why not developer?

After 1 minute of silence, someone said if you stay developer and you cross 30, you’re considered as failure. Author said “I’m 35, and I’m very proud to be a failure.”

From that day onward, things changed. The developers seemed happier, free and enjoying what they are doing, paring with each other etc.

We still have companies that treat developers like second-class professionals, who are there just to type stuff on the keyboard. Developers, on the other hand, think that this is how things work, and they do their best to move up in their careers, away from development, so they can be treated as real professionals.

Different Ladders

Every profession has a career ladder. Software development is no different: we start at the bottom and move upward as we become more experienced.

Developers who, for one reason or another, decide to take roles as managers or architects are not climbing up the software development ladder; they are switching ladders.

Roads and Milestones

There is a huge difference between following a career within a company and following your own career as a software craftsman.

Besides the things we are paid for, we should also invest all our dedication, passion, commitment, and knowledge we acquire outside working hours to make our workplace a better place—a place where everyone can learn and thrive.

Author never looked at job description and never said “That’s not my job”. He always delivers more than expected hence inspire team to do the same. He wanted to have exposure in different technologies and industry.

Author changed few jobs in their career where average they stay around 2 years, in one of the company they stayed for 3 months and another company for 5 years.

Author chooses job carefully and never share bunch of CVs to many different company with expectation of at least one of them would make them an offer.

Building Our Careers, One Job at a Time

Before Author choose a job, they ask themselves following questions:

• What do I want for my career?
• What is the next step to achieve that?
• Is this job aligned with my career aspirations?
• How much value can I add to this company?
• What is the return on my investment?
• How long (roughly) will the duration of my investment be?
• How would this job help me to get to where I want to be as a professional?
• In this job, will I have autonomy, mastery, and purpose?
• Will I have a productive partnership with my employer, where both sides will be happy with the value they are getting out of the deal?

Interview process should be 2 way street, we should ask these question to determine reverence of job with us.

Along the time, aspiration of author changed, according to that they changed their job, not only that they also considered personal goals to align with the decision.

Companies benefit from unhappy people leaving their jobs; it creates opportunities for them to bring in new people, with fresh ideas and more energy and the willingness to challenge the status quo and do a great job. From experience, I believe that a staff turnover of 15 to 30 percent a year is very healthy for a company. New people with new ideas help the company to remain up to date, competitive, and fresh.

What if We Don’t Know Where We Want to Go?

Once we accept we don’t know where we are going, we can be more focused and objective in finding our way.

In that case, expose yourself and start meeting people in communities, contribute to open source initiatives, etc. that will help you to bring more clarity.

Job Diversity

Software development is a very diverse profession, and successful craftsmen usually have very broad experiences.

Developing frameworks and tools is very different from building bespoke business applications. Developing rich web applications is very different from developing applications with no user interface.

For certain applications, a bug in production can cause huge damages (millions of dollars in fines, or even endangerment of human lives), while in others, a bug in production may not be a big deal (some users may get a bit annoyed but they will get over it soon, when the bug is fixed).

Working for a consultancy company can be a good way to get exposed to different types of projects and environments. you may have opportunities to work with different technologies, different types of software, different types of companies, different team dynamics, and different tools and processes.

Moving from project to project, experiencing different environments, companies, industries, technologies, and approaches to software, is what I would consider to be the craftsman’s journey.

The Mission

Software craftsmen are on a mission. They focus on bettering themselves, constantly investing in their own careers, and learning, teaching, sharing, and delivering value to every single client. But this mission is not just about clients—that’s just one part of it.

Craftsmen focus on helping other developers to get better at their craft and to be proud of what they do and who they are.

Being a software craftsman is about more than just waking up in the morning, going to work, and getting paid to do some stuff. Software craftsmen wake up in the morning to make things better and to change the world we live in. Being a software craftsman is far more than writing well-crafted code or being a software developer. It’s a lifestyle—a commitment to excellence. Embrace it. Be proud of the role you play in the evolution of our society.