Unless you undergo a paradigm shift.

I've heard a recurrent theme within service companies: yearning to start a product they call their own while building the dreams of others.

The crux of the issue? Organizations that have built and recruited for years for expertise and execution are now seeking to leverage the same workforce to spark innovation.

This requires an entirely new set of skills and mindsets that haven't been the focus previously. This isn't a universal truth, and exceptions do exist of course; but.

The needed change? Begin to act less as employers and more as investors. Prioritize headhunting and assembling entrepreneurial micro-cosmoses over general recruiting.

If this approach falls short, don't despair. Service companies are the backbone of the industry. Explore alternative ownership models beyond the transactions, it may align more closely with your organization's core.

They usually come time and time again with the same kind of problems:

• Someone doesn't quite get how the box model works in CSS.
• Someone never reads the documentation before shooting up a question.
• Someone doesn't seem to get how reactivity works in their SPA of choice.
• Some people never seem to find their way around their IDEs.

It's not a deja vu. These are the people for whom you've already solved the problem before. Maybe more than once. Yet they come back to you like they never saw anything like it before.

And in some cases, they haven't. Maybe they were checking social media, leaned back in their chairs, while you were debugging their environment.

In this case, it's important to set clear boundaries between what's acceptable and what's not when it comes to asking for help. It is also important to correctly define the process as an act of teaching and not one of delegating one's problems.

You can find a good example among developers without a technical background. Most of them had, in the meanwhile, became productive professionals.

Faced with scenarios in which they need to know and apply algorithms, often in the settings of a technical interview for a new job, their reactions are adverse.

I've seen many invoking reasons such as never needing to use any sort of algorithm or pattern to conduct their day-to-day business. Which can be true.

The issue arises, when they turn to shame companies that have coding interviews as part of the recruiting process.

Here's why this is an issue:

1. Making an uneducated guess about the job requirements. If it's part of the interviewing process, it might have historical reasons to be.
2. One might overestimate one's expertise.
3. One might be glorifying incompetence. You can read more about it in this article from DHH.

Instead of closing your mind on the difficult topics in our line of business, I adivse you embrance it as it is: a learning process. With education, in general, It's better to start later than never.

How many times have you not heard someone say: "It works! I don't know why, but it works!", or: "It's not stupid if it works."?

Many times, with a misplaced sense of pride attached to it.

While it can happen for objective reasons such as meeting a short, non-negotiable deadline, it is usually the result of a deeply ingrained habit among developers, that of considering working code, satisfactory code. Ignoring, in their way, readability, maintainabiliy or efficiency making it hard to collaborate and iterate for everyone involved.

The solution is to make refactoring a mandatory part of the development process for you or your team. Strictly adhering to the boy/girl scout rule can also be a good measure to increase one's awereness over own codebase contribution.

I've naively thought, at the beginning of my career, that behavior-driven development, through the prism of my social sciences background, was all about the programmer's personal conduct and professional habits. To my surprise, the practice of BDD refers to a different subject.

Still, the passing of time and a position where I was responsible for recruiting, on-boarding and training new talent confirmed to me that my intuition was right: More than rigid methodology and complex programming practices, habits and attitude can influence the success of a software project just as much as its architecture and management.

In the next few days I'll detail some of the most impactful patterns.