It has taken me some time to really follow the best practice of checking references, both before hiring of new employees and of external contractors. Now I don’t move without it. The main reason that I didn’t check references is that it seemed to be a useless process, every reference I talked to always said great things about the employee/contractor and I never seemed to get anything useful.
Now, I get invaluable information from the references, at times it
This was because I didn’t ask the REAL questions, now I have found what questions to ask and the key is to LISTEN, but really listen, to the answers given.
The questions are:
1. How long have you worked together?
2. What didn’t go well? What were you NOT pleased about?
3. Would you hire him/her again today?
4. Did you ever think of leaving/firing him?
5. Try to help me out here, if we are going to work together, what would be the problematic areas? What is going to be tough? Where can I fail?
Tip: If you don’t get an answer, say, No one is perfect, unless someone is paying you, there must have been some things that went wrong.
(Make sure to keep a written record of all conversations to put in a candidate’s file.)
During the Typemock Partnership Academy Panel in Oslo, I had a very strange feeling coming from Uncle Bob, when asked “what is the state of unit testing” that was the feeling of acceptance, but I felt a tingle of consent perhaps a bite of giving in.
“We are on track, everything is ok, the state of unit testing – is the state of unit testing, so their is no place to feel happy or sad about it” and “it will take 20 years, and that is ok, most of us, the ‘bad’ developers will die out and be replaced by craftsmen”
Gil Zilberfeld although quiet, nicely pointed out: “I feel like I am listening to a Buddha Guru”
I feel very different, I know that 90% of the developers don’t unit test. That is 9 out of every 10 developers, that is outrageous, 10 years of unit testing and only 10% of the developers – get it. Some developers we have interviewed said “Yup, I tried unit-testing, it is just a way for management to make us write twice as much code in half the time, I will never do it again”
As Roy Osherove pointed out, there is talk of dividing the developers into 2 groups, “Us” – who unit test, and “Them” who don’t. “We won’t even try to teach them, its their loss.” I can see where this comes from, we would prefer to hire only developers who unit test their code. But the truth is, in hindsight, the majority of the developers working at Typemock, didn’t know how to unit test and learnt it on the job. I actually think that there is already a separation, There always has been one, between the purist (Whether it is Strict-Object-Oriented, UML-Modeling, TDD, craftsmanship you name it) to the pragmatic developer: The highest level of joy, is seeing our product being used, so we need to understand our users, create something that is useful and joyful for them, with the lowest cost of ownership. We will use any tool/process/trick to make this happen.
I had a great discussion with Richard Fennell from Black-Marble over breakfast. Richard told me that Management in companies are focusing at investing millions of dollars on the “user-tests” and see those tests as the ultimate QA solution, while hardly any invest in unit-testing. “We have no quality problem, because we have a QA team”. Now the QA market is a huge and very strong market and unit-testing is a threat to that market. I have heard many QA people, thinking about how this will make them lose their jobs. Richard talked about the normal software developer, who doesn’t have the passion that we have, that see their job as “a job” and don’t spend their free time going to conferences and writing an open source project, they just want to get the job done.
Perhaps this easy-going, let’s wait this out, attitude, is what’s hindering the acceptance of unit testing in the world. It is clear to me that 20 years is too long for this to happen, I know that there is another way, that technology and business value have the power to make that transformation become real.
I have just come back from a really successful and fun kickoff of our partnership program (web-site up soon). But everyone is asking me:
Well the reason is not because of the fresh fish that can be found in Norway, even though I love salmon.
It is not because of the great people, who are well mannered, exciting, smiling and smart, even though I had a great time meeting them
It is not because of the great hospitality that we received being guests in Norway, even though I was helped when we got completely mixed up with the local and express trains
It is not because of the social system that they have their, even though I would love to see such a system back home
The best way to convey why we chose Norway, probably comes from their Viking heritage, and while in the hotel I picked up the following postcard:
Did you notice: “Be versatile and AGILE”
So being Agile is actually a Viking thing, and that is probably why, in the end, we chose Norway to start our partnership program.
There is a higher percent of developers unit testing in Norway then in any other country, The number of customers and partners in Norway is way above average and they really understand and embrace Unit Testing.
It seems to have been the correct choice, the consultants I met are superb, they are open to idea, very technical but business minded too, and they also know to have a good time.
Continue to “Be Brave”
It’s been a while since I felt so excited and proud at the same time. We are three days from the official launch of the Typemock Academy. And even though we’ve been celebrating 5 years of easy unit testing the whole month, and it’s been quite a ride, the Academy launch is a Big step forwards, and a landmark occasion.
It’s been 5 years since I founded Typemock and looking back I can’t believe how much we’ve come forwards. The academy is not just the academy – it symbolizes looking forward, the Future of Typemock.
It wasn’t that long ago that we realized the partners full potential – and here we are, launching the first (of many!) Typemock Partner Academy. As amazing as it seems, we never approached them before or asked them to be our partners. We found out that there are consultants and industry leaders all over the world that are recommending and implementing Typemock’s tools because they realize that that will help their customers. Now it’s our time to organize it, and to give back; by giving them the knowledge, the back up and the tools in order to continue what they do and to help their customers benefit even more from our products.
We are answering the industry’s call. We’re telling you – come and partner with us and support and bring the message of a craftsmanship code to more and more developers all over the world.
See you all there!
There has been a lot of noise about software craftsmanship.
I think it’s great that people are talking about how software development should become a true craft.
When I look at what the developer groups talk about online…they discuss design. But I have seen many good developer discuss (read: rant) about how no one listens to them, no one knows how to do things right, the result will not work, the design is not good enough…and so on. That kind of “talk” simply does not lead to craftsmanship.
Sitting in the aisles and ranting about how things won’t work, is probably the least efficient way to finding out what does. The first step towards true craftsmanship is to ask “How can we make this work?”, “How can I help make it work” and not “Why my way is better” or “How this will fail” You will be able to do wonders when you look for ways to make things work, and not, why they will fail. It is a small perception game, but a very powerful one.
The way to craftsmanship is Getting it Done, and not Doing It My Way
Years ago (well not that many years)…when I was working for a large company, I was asked during my midyear review to identify my goals.
I remember that my immediate reply was to ask for the group’s goals, because with that information I could figure out my own goals, as a member of the team. Looking back, I wonder how they could have asked me for a goal without telling me the larger goals first. The process was with no doubt broken. I remember promising myself that when I become a manager, I will always tell my team the company goals so they can best help achieve them.
But, as time passed by, when I founded Typemock and became the CEO, I must admit that I haven’t always lived up to my word.
My wakeup call was when we had a very large financial project to produce and submit. After we sent the report to our CPA, I received a hysterical phone call from my accountant that my numbers don’t fit. I checked and realized that the reason the numbers were wrong was because the goal was not communicated properly to the people in the company. My team did everything right. They did whatever they could to meet the deadline. They didn’t wait for me. They worked as a team. But I didn’t explain the goals properly.
"Ahhh, so that’s what you meant." A few hours later the numbers were sorted out.
Once I explained the goals and they understood them, they helped fixed the report. If they knew what the goals were from the beginning, the drama would have been avoided.
One of my trusted marketing advisors has a unique and successful tool: the project brief. For every task, he first writes the goals and the sub goals and then the course of action to get there. By sharing the brief, the team has the information they need.
For example, with Test Lint, we want to have web pages for each of our golden rule. Saying that we need a page will probably get us nice pages but the goal is missing. Writing down that the goal of the page will lead to different results. So if our goal is to teach the developer to create great tests, we can explain the reason why the rule exists and how to create tests that follow the rule. Communicating the goal directs the task, and keeps the team focused on the same end result.
As Covey says Start with the End in mind.
The answer to ‘How do you decide what to delegate?’ Should be very easy. If it is not one of your core competencies, give it to someone to whom it is. That way, you focus on what you are good at, and they do the same. Yes it’s true, that sometimes the best way to delegate a project is to outsource it.
My way to decide is to ask myself the question “do I want to spend my time coaching, mentoring and growing the required skills in-house?”. If I don’t then the answer is to outsource it.
Take for example graphic design. We don’t have an in-house designer, and while we have talented people on our staff that may be open to learning new skills, keeping a graphic designer, coaching and mentoring him and making sure that he is always growing would not add to our company’s competitive advantage. So we went to outsourcing. Even if we would have hired someone to work in-house, with all the required skills, do we really need to invest in growing and empowering a graphic designer in a software company???
A few posts ago, I posted Boss: Don’t DELEGATE about delegating within the company… So you can only imagine how I feel about delegating to contractors. It’s even harder than delegating in-house.
In order to feel more comfortable and to make it work, the contractor needs to understand the bigger picture and be empowered to deliver the best possible results. In our company, we invite our contractors to the office for a monthly meeting to update them regarding our goals and milestones, and to make clear their roles in achieving them. Communication is the first secret of success. So far these meetings are showing their fruits, our contractors are part of the big picture and it’s the second secret for their success.
But the most important part is, of course, there must be someone in-house that maintains responsibility and manages each and every project or outsource company.
I call it the 200% responsibility. The contractor is responsible for his work, but so is our in-house person that is managing him.
To illustrate the point a non-office issue that can explain the importance of the 200 percent responsibility:
Say I need to pick up my daughter from School and drop her off at home with her mother.
I will stop the car and will make sure that my daughter is safe as she’s crossing the street – my 100%. At the same time, and regardless of me, my wife will be watching my daughter crossing the street from the moment that she leaves the car, until she is with her – 100% responsible. During the time that we are both watching her, while exchanging responsibilities, we are both 100 percents responsible – 200% responsibility. I am 100% responsible for getting her there safely. My wife is 100% responsible for her getting to her safely. There is no room for partial responsibility.
Coming soon: Hiring workers who are expert in fields that you are not, or ‘How to interview potential workers when you don’t understand what they do’.
Unfortunately I can’t tell you about our next product as of yet, but I can promise that you will hear about it very soon.
What I can share with you is that following the great success of the Isolator, we weren’t sure what our next product should be. We wanted to help the developer, and yes the first time we got it right, but what next?!
When I first got my iPhone, I was so into it that I found myself using it all the time. One evening I sat in the living room, playing with the apps when my wife said “you are always on the iPhone. I don’t know how to communicate with you anymore.” Before I could reply, my 7 year old daughter said with a huge smile, “through the iPhone!!” What a young marketer, She quickly identified the need and its easiest solution.
We tried to emulate that kind of straightforward thinking when we decided on our next product. It wasn’t easy but eventually we understood that we must actually know and not just assume what the market actually needs.
We conducted marketing research FOR THE FIRST TIME. Leaving the Echo Chamber, we had to check what our target audience wants and what products and services they need.
The process was not easy. A trusted advisor said “I can do that” and then she and I had to convince our team that this was the right step. Convincing everyone was very hard, even when they went to see the focus groups about developers and what their pains are. When we saw the developers’ needs, each one of us saw them through a filter of our preconceived ideas, seeing only what we wanted to see, and reaching individual conclusions.
Finally, we compiled the conclusions to develop THE idea to solve a problem or a pain. Only after we started writing it, we started to understand the power of what we were doing.
A key learning was that we don’t have the same needs of the developers that we develop for. There is a difference between those who build features for developers and the developers themselves.
But if you are reading this blog you have probably already “seen the light”. You probably want to learn how to connect your developers to their customers. They don’t necessarily think or act like you. We are all developers but with different needs.
Breakthrough breaking a wall…
Our here-on-earth mission is to help developers write unit testing that help developers and respect the occupation of development.
Reading a blog post about leadership versus being a boss, I started to think about this matter again. I honestly don’t think that we need any more leaders – we actually need people to execute tasks.
Speaking of leaders, I’d rather call them coaches; coaches are people who understand that their largest task is to grow their team. A coacher doesn’t depend on Good Will, nor will he fix the breakdown or say “WE” instead of I…a coacher will make sure that the team has the tools to find how, and to fix the problem themselves.
The coach is a role model: he never expects others to do what he doesn’t. A coach is the one that turns the triangle upside down and putting himself at the bottom helping out.
A coach is the one that empowers and will guides. He is the mentor.
Roy just asked me to blog about a twitter-conversation on our Typemock patents.
It is true, we do have a patent. Its number is: PCT/IL2007/001152
It is natural for companies to file patents of their innovations and inventions.
We have no answers to the questions that where asked and we haven’t any policy about this as this is not important enough.
What is important and what we are focusing on is that less than 10% of the developers actually write unit tests! We are focusing on innovating to get the right tooling that will enable the majority of developers to unit test their code, becoming craftsmen and professional and take the whole software development community another step forward, not on delaying innovation.
image by ihtatho
- Product Status Peek – 2011
- Thanks Roy
- Typemock starts 2011 in a new location
- Agile Demos Smells
- I want loud disputes in our meetings
- .NET Tests
- Code Integrity
- Management for Geeks
- Time Management
- Unit Tests
- January 2011
- December 2010
- October 2010
- August 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006