Vukoje's blog about software development

Writing awesome dev job ad

Why write about job ads? This is blog for software developers, not HR and marketing. Well, can you really expect HR to find you good developers without your help? Yes you, the freak with the keyboard.

My company wanted to hire more talented programmers and the question was how to do this within limited time and budget? There are many companies fighting for good programmers, how can we step out?

I gave it a thought, what I can do to change this in our favor and I concluded that I should rewrite our old generic corporate developer job ad to something awesome. So I did it and we had pretty good result. You can see new job ad here.

Read on to see what were my guiding principles.


What’s wrong with old ad?


The ad is generic and boring. It doesn’t distinguish us from any other company.

Section describing candidate responsibilities should go without saying because it describes almost any dev job and still you have no idea what you would be working on if you get the job.

We ask for RequireJS experience. Really!? I can teach it to good dev in 1 day. I think you should rarely insist on experience in some technology if that is something that can be learnt very quickly.


How to be better?


Here are my guiding principles for writing new ad:

  • It should be written by dev for dev.
  • It should state all the things I like about my job. Yes coffee and parking are important to me, they make every morning start a little nicer. Why not share it with others.
  • It should mention all the things we built and are proud of. Programmers love challenges and project where they can learn new stuff. If you have them, than brag you fool!
  • No bullshit and empty talk.  Marketing lead, friendly work environment, bla bla… say something concrete and interesting.
  • It should be funny. Why the hell not! We try to have fun at work every day and we are very proud of our work atmosphere. Why be boring when it comes to a job ad?
  • It should be in native language.


How did it go?


It went great! We had way more job candidates than normal. Usually we hire 1 good programmer after we put out an ad. This time we hired 3. Few candidates said that they applied only because they liked the unusual ad. We got CV’s and emails from candidates that were personalized to match humor from our ad.

All of this because of little honesty and humor. Don’t be boring!


Programmers under pressure

In my previous blog post I have mentioned that most of our job candidates state in their CV-s that they work great under pressure. The thing is ... nobody works grate under pressure. The only difference between people is whether they break under pressure or not.

The pressure is something well known to probably every programmer, but hopefully it isn't present every day. When I say pressure, I don’t think of managers forcing programmers to code for long hours. I rather think about situations when you must finish something that you care about very much, but the situation makes it almost impossible.
This is often the truth for developers because we:

  • have deadlines,
  • do complicated things that are error prone,
  • lack engineering practices and tend to throw the ones we got the first time we hit the wall

Because pressure is probably guaranteed thing, first thing we can do is become aware of it. I have met two kinds of pressure: negative and positive.

Negative pressure

This pressure emerges once you start to break your deadlines only to find out that your solution didn't satisfy customer requirements. The code is very bad, there are problems everywhere and everybody is pushing the problems under the rug because there is too much of them. Nobody can get anything done because of the piled up impediments and codebase that have become super complex and meaningless. Even when you get something done, you later find out that some existing functionality was broken by your changes. You wake up in the morning sick of thinking you are going to the same unsolvable problems again. At the end the tension between teammates becomes evident because someone must be quality for this state. Is it the programmers, the testers, the managers?

The only positive thing in this situation is that you will learn many things that you shouldn't do as a programmer because they will come back to bite you. Also you will have a scary story up your sleeve that can come in handy when you need to dramatize bad practices that could cause another project to get in this state. Until this state becomes just an anecdote, listen to Freddie Mercury's advice, it may help.


Positive pressure

Negative pressure is pretty obvious with its causes and side effects, but positive pressure is something much more subtle and hidden. It happens in opposite situations, when group of people has a big challenging goal ahead of them. This is never an easy task but everyone is doing the best they can. You could say that everyone is striving for perfection. Because perfection is impossible and mistakes are happening, the positive pressure emerges.

When people in these situations are really really dong the best they can, thinking of the challenging problems when they go home, trying to help everyone, they become very tired and sensitive. If they feel that their efforts are unappreciated they will be devastated. The more everyone is committed the more likely they will neglect this social component of successful projects.

As you can see, there is no real problem here, because this is only a slight problem in communication, but with possible serious outcomes. So if you identify positive pressure, talk about it with your collages and say how much you appreciate their work. Everyone will feel that they are fighting on the right side again and keep doing the best they can.

CV trash talk

Last few months Soprex was hiring new people which also meant I had to:

  • read a lot of CV-s
  • hold technical interviews
  • judge people
  • neglect my regular duties


As you can guess I wasn't too happy about it because I had other important staff to do and I don't like judging people, especially not based on some resume.  But still, this is a small effort compared to potential impact on our firm. Last thing you want to do is to misjudge people and spend few months getting them in the business to find out that it is not going to work out.

David Parnas said:

Q: What is the most often-overlooked risk in software engineering?

A: Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.


CV content

The whole CV evaluation process would be much simpler if CV-s I have read were better written. When I open a CV I want to see candidate's:

  1. Age
  2. Picture
  3. Education
  4. Working history and experience
    • names of the companies and employment period
    • projects on which candidate has worked on, with short description of project domain, used technologies and candidate's role in project

I was horrified to find out that most of CV-s didn't include information about candidate age nor his/hers picture. You might argue that these are not relevant factors but I think they are, especially once you want to build picture about some person in few minutes.

Information about education was usually present but it was usually encrypted in English form so we were constantly guessing which colleague candidate meant.

On the other hand, working experience is the key information and it was almost always present in some form. If we had additional questions or misunderstandings regarding it we called candidates on the phone to ask them additional questions to get a clearer picture.


CV trash talk

With all this badly written CV-s and my other responsibilities, I was trying to make a person assessment keeping in mind that great engineers don't necessarily write great CV-s.

Above all listed problems one really annoyed me, the corporate trash talk. The worse the candidate was there was more trash talk. It turned out that every candidate:

  • is motivated to work in dynamic environment
  • is eager to learn new technologies and advance
  • works great under pressure
  • is a team player
  • has excellent communication and organizational skills
  • is self-motivated and self-organized
  • ...

Disaster... I am not sure why is this corporate trash talk culture happening but it’s definitely out there. One thing is for sure, it is not the truth nor relevant and I don't want to read it.

The horrible truth


At some point I started to nag to my manager that I don't want to see any CV ever again. So she showed me the horrible truth... my own CV.

Oh my God! I haven't seen it for almost 3 years and it was horrible. No I'm not going to show it to you. I will just show you a small quote (trash) from it:

My Objective:

To use my IT knowledge, theoretical and practical software development and management skills in dynamical environment which will give me opportunity to advance in further professional carrier.


Lesson learned

Guess what I learned is that you can't really judge a person by his resume but at the end you have to. You must try to read between the lines (trash) and you must not hesitate to spend a lot of time on it because new employees can make a huge difference. You might be getting your new super-problem-solving-best-friend or your worst nightmare. 

Missing data gathering also turned out to be useful. Few minutes of talk over the phone can make much difference in understanding some resume and making better and faster decisions. It would probably help if we created some CV template or little guide for writing it.

In the effort to follow my own CV advices I have updated my objectives.

My new objectives:

  1. To satisfy customer with the simplest solution
  2. To get better at it


Earliest Feedback and Sanity Checks

When two men in business always agree, one of them is unnecessary. ~William Wrigley Jr. 

This is another post dedicated to team communication. In previous posts I have already stated that communication is important and that two people are more likely to solve problems. Today I will talk about importance of early feedback, and regular developer sanity checks.


Earliest Feedback


In every agile development early customer feedback is very important. Today I will talk about even earlier feedback… I mean feedback from your team members. This is earliest feedback you can get and maybe most important, because often this is only technical feedback you can have.  If you are building some API or planning some architecture, than at that point other programmers are your customers as your API users.

The question is why is this feedback needed any way? Thes because variations, combination and potential code usage scenarios are uncountable. Ok, maybe they can be counted, but rest assure that when the time comes, you will not have them all in you head. One more thing we want to avoid with this is over-engineering.

So tell your ides to your teammates and ask them for opinion. If you do this, you will often hear the phrase "The problem with that is...". And there it is, one future gotcha you have just avoided.

In the past I was annoyed with this feedback that was constantly proving my "super" ideas wrong, but today I cherish them as a proven strength of positive critics. Always give, cherish and encourage positive critics in your team.

Another way to look at this early feedback is as early WTF?!. Instead of living some other developer  thinking many WTF!? while trying to understand your code, you cam tell your ides and wait to here WTF!?.


Sanity Checks


Programmers, as pure technicians, tend to lose focus to business value and end goal of software they are building. Once they dive deep in to code they can forget customer needs, deadlines, weak plans, planned designs… heck we will forget our friends and families. You can say that, from business perspective, developer have gone mad and this is why regular sanity checks are very important.

This is exactly why in Scrum you need Scrum Master whose main role will be “sanity checker” (team conscience) who will be checking developer sanity on daily scrum meetings. On these meetings every developer answers 3 questions:

  1. What have he done from last meeting?
  2. What will he be doing until next meeting?
  3. Does he have any problems with his work?

After everyone has answered these 3 questions, whole team should be informed about each other’s work but also it should be obvious if someone have gone insane. For example, developer could answer that he has not been doing what was planned and has started to build his own parsing tool in some experimental technology that will be supper cool.

After this madness is discovered, everything is easy. Scrum Master asks simple question: “Why?” and keeps repeating it until developer realizes his mistake. This is known as 5 Whys technique.

Do your team sanity checks and check yourself daily. Focused team, building minimum that customer required can do amazing things, so go and be amazing.

Things learned at Scrum Master training

Last month I have attended Scrum Master training at Faculty of Organizational Sciences in Belgrade. My mentor was excellent Dan Rawsthorne, with huge experience in production and strong hold in agile development. His experience gave his opinions huge credibility and his agile approach gave me a completely new view point to Scrum compared to one I have gained from Ken Schwaber’s book.

Here is list of my most interesting notes from training:


  • Brains solve problems, not processes. Process should only exist to enable focusing on brain power. Scrum is designed to force us to make hard decisions.
  • Agility is opposite to prediction. We can not control the world, we can only adapt to it and that requires constant attention which is hard. Waterfall gives illusion of control and false comfort.
  • Every team member is doing the best they can, but not the best they could be doing.” This is really interesting statement and I think that one should always remember it when evaluating and improving team abilities.
  • Programmer’s job is to create value, not to write code.
  • Perfect is the enemy of good. Good is what we want, perfect is impossible.  
  • There are no “I don’t knows” in Scrum, every decision has to have good reason which should be known to all (or most of) team members.
  • Scrum is about committing, not about knowing. If you focus on knowing, you will be too slow. If you are not sure, build something and get feedback as fast as possible. You are committing to agreement, not to tasks. Tasks are there to help you commit. Do something and than get better.
  • You can not build quality back in to the code, you can only replace it. Regular questions like “Has anyone written code he’s not proud of?” can help identify problematic implementations. If they can’t be addressed right away, related correction tasks should be added to product backlog.



  • When product is reviewed on meeting, developers have urge to demonstrate unfinished functionalities and demonstrate only happy paths in Use Cases. Unfinished functionalities create false impression of faster product development which can only lead to shortening of deadlines and later confrontations with stakeholders. “Happy paths” often hide real world usage scenarios that are most problematic and that should be discussed the most.
  • Always time box exploration tasks.
  • Scrum Master can lead only one team because it is full time job. SM can also be team member, but you have to bear in mind that his team duties can lead to neglecting of SM responsibilities. SM shouldn’t be Product Owner because that would concentrate too much power in one person that can destroy self organization and initiative if SM doesn’t control his urge to control. Micromanagement is obstacle to self organization.
  • At the end Product Owner is the boss (decision maker). Team can only do it’s best to prove its concepts. PO has veto powers all the time, but he should control urge to use them.
  • Scrum doesn’t fit teams that aren’t constantly trying to improve them selves. If you can't imagine your tem being self organized and taking initiative, then that is probably because you really can't, and no methodology will help you.

Preparing for Scrum Master certification

Previous weekend I was preparing for gaining Scrum Master Certificate. If Scrum is new to you and you are interested in it, I strongly advise you to take a look at this video where one of the Scrum inventors is talking about its implementation at Google.

In preparation for Scrum curse I have read Agile Project Management with Scrum by Ken Schwaber. The book is excellent and I recommend it to anyone interested in Scrum. Thing I liked the most about it was the way book was written. Main thing about Scrum is that it is simple, pragmatic and lightweight and the book is just the same. Book is short, simple and knowledge is passed to reader through real world examples. Most of these examples were examples of Scrum misusage, which are extremely valuable because they keep us from repeating common mistakes and at the same time enables deeper understanding of Scrum driving forces.

Next thoughts were most interesting to me:

  • Role of managers is to shape the organization not through the power of will or dictate, but rather through example, through coaching and through understanding and helping others to achieve their goals.
  • There are three legs that hold up every implementation of empirical process control: visibility, inspection and adaptation.
  • Scrum uses power of time-boxing to instill the art of the possible and avoid pursuit of perfection, the practice of incremental delivery to improve engineering practices, and the practice of empowerment and self-organization to foster creativity and worker satisfaction.
  • Every increment of potentially shippable product functionality that is demonstrated at the Sprint review must be done. Done means it contains all analysis, design, coding, testing, documentation, and anything else appropriate for application.
  • Many development teams accept the risks and don't discuss difficulties and options with stakeholders until the end of the project. This is natural result of an environment in which developers don't really know where the project stands any better than management does.
  • Scrum relies on high-bandwidth, face-to-face communication and teamwork. Cubicles and unneeded artifacts promote isolation and misunderstandings.
  • Build the infrastructure for scaling prior to scaling and always deliver business value while building it.
  • You can get through almost anything if you don't try to impose rigid solutions before problems even arise, instead devising solutions as necessary when problems crop up.
  • Retrospectives that don't result in change are sterile and frustrating.

In my previous post what to code next, when I discussed choosing next module for building I completely ignored importance of business value and ROI (return of investment). This was noticed by my dear friend Aleksandar Mirilović (who's blog is still under construction) and confirmed in Scrum. Fact that something has greater business value or is urgent can not be ignored. Also business value is excellent test for early system architecture. If you respect ROI and deliver complete functionalities at the end of each print, you will be able to go live with incomplete product at any time, which I argue is very valuable flexibility for business.


In my next posts I will cover things I have learned in course so stay tuned.

Do you have any real world experiences with Scrum? Are you planning to?