I was thinking today about a certain aspect of running a software startup and then it came to me...

Hank Scorpio, from the Simpsons, was right in his approach.

So many time I have seen people get hired only for the company to get a less-than-optimal performance from them.

But why is this? Of course, it is many factors but one of the major ones is...

Employers seem to lump employees in together and assume that since most developers operate in one way that the new devs should be the same way.

The problem with this seems to be that we are all pandering to the lowest common denominator.

Let's face it, most devs (like most people) are not good, and almost everyone is not living up to their potential because of a lack of understanding of themselves and how they can achieve more.

On top of that, most devs are just employees who will do what you tell them to.

Since those above developers are the norm (Reference Seinfeld "95% of people are undatable") we have to assume that there is a 5% who are exceptional.

The difference between the 5% and the 95% is NOT some built-in superiority but that the 5% has a good idea themselves and an understanding of how to get the most out of them. They set goals and then find the right path to achieve them. They don't coast.

By assuming these developers are the same as the others is REALLY hampering their potential and by doing this the company only hurts itself.

So, that's a lot of talking but what actionable things can be taken away from this?

Hank asks Homer "What is your dream?"

Well, employeers should take the time to identify which of these developers are in the 5%. A problem arises though when the 5% decide it is in their best interest to blend in.

Like when home says his dream is to "Work for you?" Hank shuts him down and wants to get to the truth. He makes Homer comfortable with not only vocalizing but achieving his dreams.

When an employer is looking for their types they should be looking for the following...

1. A real genuine desire to achieve
2. A real plan to get their goals done
3. Critical thinking and self-evaluation

But more importantly, when they identify these types they should be asking questions like...
- How can we help you be more productive?
- Is there anything about our current operating norm that is hindering you?
- How does your productivity workflow look?

3 difficulties arise though…

1. Most hiring managers are incompetent, and quite frankly, everyone thinks they are in the 5% and for those managers who delude themselves into this without putting in the work, they will have an impossible time actually identifying those who are actually good and productive employees.
2. Showing special treatment to these folks may upset the people below.
3. You will hear things you don’t like…

Examples include…

- That new fancy open-office that you got because it was the trendy thing to do, you might hear that this is a huge hinderance.
- These days people seem to treat devs like nomads, “just give him a laptop and a table and he is fine”!. You may hear that this is complete BS. Real achievers may want a dedicated desk with multiple monitors, a desk with drawers etc.
- This WILL cost you money. I know of developers who cannot work without a dedicated whiteboard. Buy them whatever they need.
- They may want BOTH a standing desk and a chair to sit on.
- Etc.

The point is that it seems to me to be a foolish strategy to tailor your entire company to force everyone into the same work habits. Really good employees have the self-awareness to develop their own productive practices and any keeping of them inside a box will NOT help.

I found this on a wiki with Haskell Humor... it's interesting...

How to Shoot Your Self in the Foot With Haskell: Putting the unsafe in unsafePerformIO!

You shoot the gun, but the bullet gets trapped in the IO monad.
Couldn't match expected type 'Deer' against inferred type 'Foot'.
While compiling your program the compiler produces a type error long enough to overflow a kernel buffer, overwrite the trigger control register and shoot you in the foot.
After trying to decipher the type errors from the compiler, your head explodes.
After you've finally found a way to circumvent the type system and shoot yourself in the foot, Oleg appears out of nothing and shoots you in the foot for coming up with it before him.
You shoot the gun but nothing happens (Haskell is pure, after all).
Your foot is fine, until you try to walk on it, at which point it becomes mangled.
You have a shootFoot function which you've proven correct. QuickCheck validates it for arbitrary you-like values. It will be evaluated only when you end up at the hospital. You hope this doesn't come to pass, as it actually returns a bullet-ridden copy of yourself and you don't want to be garbage-collected.
foreign import ccall "shootparts.h shootfoot" shoot_foot :: Gun -> Programmer -> IO ()
shootSelfInFoot = unsafePerformIO . shoot . foot $ self -- Shoot self in foot 0 or more times depending on evaluation order
No instance for (Target Foot)
arising from use of `shoot' at SelfInflictedInjury.hs:1:0
Possible fix: add an instance declaration for (Target Foot)
In the expression: shoot foot
You go to shoot yourself in the foot but the bullet is in the ST monad and the gun is in the IO monad, so you can't.
You ask Haskell to shoot you in the foot but by the rules of lazy evaluation you don't need the result yet so it doesn't happen.
You decide to shoot yourself in the foot but get distracted devising a ballistics algebra and wondering if you can do the calculations in the type system.
You want to shoot yourself in the foot but realize there is no Gun datatype so use Arrows instead.
You shoot in the direction of your foot, but since you are inside the STM monad you can just retry until you figure out what to do.
You shoot yourself in the foot, but you are perfectly fine as long you just don't evaluate the foot.
You shoot yourself in the foot, but nothing happens unless you start walking.
Don't forget about memory consumption! If you don't look, the bullet causes heap overflow. If you look, the bullet causes stack overflow.
You *appear* to have deliberately shot yourself in the foot, and yet your program actually runs perfectly OK due to lazy evaluation. (So long as you remember to not look at your foot...)
You aim the gun at your foot, pull the trigger and remove the clip. When you look at your undamaged foot, the hammer clicks on an empty barrel.

Ok so as the only developer in a tech startup who is mostly self-taught i've decided to take the initiation and do some online certificates and diplomas
bagged 2 now
1 Python programming
2 Business frameworks and IT for Orgs

For the employee goals evaluation, my manager suggested to word "the higher-ups difficult to deal with on the other parts of the world" as "handling complex and challenging situations due to time zone differences"

any advice for how to write an effective annual self-evaluation?

I feel like I'm always doing my best to contribute to the team and handles all task assigned smoothly but looking at the daily notes of what I've done since last year they all seem so trivial ==''