Two harmful mistakes every developer should avoid

There are several traits of a successful employee every hiring manager seeks for. There are as well several mistakes a developer should really avoid. Those mistakes usually cause much trouble!
When I set to hire someone, I tell him explicitly that I can’t tolerate 2 of those unless agreed upon during the sprint/iteration life cycle.



A Deadline is a major thing, I like to call it a : holy date. Many developers don’t get the importance of deadlines unfortunately. However it’s simple: all teams depend on this date, business, marketing, pm and finance teams. When you have a problem setting this date, you simply screw everyone’s life, starting by shifting business plans and then adjusting other plans accordingly.

That’s why I ask new employees to take their time in giving estimations. If you need time to research something, then fine: ask for it and take it.

Use Gantt charts to do estimations. A task time shouldn’t exceed 4 hours, otherwise you have to split the task to minor ones.

Add time margin to your estimation. Some developers tend to be optimistic. Certain problems might arise. That’s why I ask all developers to add a margin of 2-3 days depending on the sprint/iteration length.

If something is blocking you then you need to raise it ASAP. If for some reason you can’t meet a deadline, then raise it ahead of time.


Code QualityCode quality is the most important factor in evaluating someone’s work. However, that’s not the reason of its importance. The importance of code quality comes from the old known fact; your code will be maintained by you or others in next iterations of the project.

If you deliver low quality code then, most probably the code will have to be rewritten after few iterations. Simply, you’ll waste months of planning and work.

However, code quality has no clear standards in terms of expectations. This is something that you need to consider and revisit every while and then. I ask team leads to set those standards in both design and implementation. Personally, I like both the SFEMS and the SOLID principles.

Pair programming is by far, the most reliable option for code quality. Testing is another one with a little cost of time at the beginning of practicing.

Both deadlines and code quality are so much important factors that help shapes the ninga of you. Please work on optimizing those skills. Stick to your team lead and take his advice when needed. It’s all about experience after all!

3 Factors for a Successful Startup

Startups, like everything in life, have some key elements for success. I’m listing here what I think are the most important factors to help you moving your idea to a successful startup.

((The order here is irrelevant and all have the same equal value))


So you have the idea and you believe it’s the time to move forward. This is the proper time where you should prototype it. The purpose of prototyping is to collect enough feedback to decide whether you are going to continue and in which direction or cancel the idea altogether. Also, the prototype is helpful for marketing the idea and making relations.

The prototype should be the minimum work required to demo the idea for a group of selected people. Ideally the prototype takes 2-3 days of work. However, sometimes you need more time to demo the idea but in worst cases it shouldn’t take more than 2 weeks, otherwise you are actually coding the idea, not prototyping it, which is a totally wrong decision.
After you prepare the demo, pick a set of people including business guys and collect their feedback:

  • They do like it: This is the ideal situation. Congrats!
  • They kinda like it: This is the normal situation where you fix the workflow  and decide your next step basing on the feedback you get.
  • They don’t really like it: This case is usually referred to as “Fail Fast” or “FF”. Don’t get disappointed, make use of the feedback and rethink the whole idea. Most likely you will start from scratch with a new startup idea.

Business model

Here is the golden rule:

Launch first, then figure out the business model  is the recipe of disaster

Relaying on the “coolness” of the idea is a wrong thing. It’s all about business after all, and investors would like to understand how you are going to generate money. Actually not only that; they would like to see how confident you are when it comes to business model.

Start putting the business plan before you do any coding. Supported with estimated numbers,  the business plan will help you take the proper decision at the proper time.Adding features, updating the product, marking, expanding to new markets or even seeking fund shouldn’t be arbitrary decisions. Instead, they should be taken when needed and based on your business model.


Believe it or not, the team you pick might be the most important factor. The qualifications and the passion are the characteristics that you should look for. Even investors considers those ones, and that’s why you hear them saying: “It should be your bread and butter”. Many startups were bought or invested in because of the teams behind them apart from the business they do.

Pick your team carefully. Don’t fall in the trap of creating a bunch of geeks team. Instead, pick qualifications that you personally lack.  Having a business guy or a marketing one working with you is highly recommended when you lack those abilities of talking or marketing your work.

Don’t underestimate the role of passion when you pick your team. Passion is the work soul, it drives the work flawlessly in good times and makes it immune in bad times.  Many startups succeeded because of the team’s passion despite the bad times they faced, and vise versa, some of them had talents but lacked the passion and finally they failed miserably.

Feel free to add your comments on those factors and what you think might also be a missing one.