Raba - Defend your code RSS 2.0
# Monday, December 31, 2012

Back to writing,
Following my last year experience interviewing over hundreds of candidates I was looking for the ingredients for making you better than your colleagues.
I know that the internet is full of such tutorials, especially one minute before the new year’s eve, but I will try to add my own twist, give you some tips and share my own goals for each bullet.
The goals were designed to the LCD (lowest common denominator) – feel free to increase the goals as you go.

Rule #1 – Read blogs
I found out that the world is trying to tell you something which most of the time is that it has a lot of new things that you need to try and learn
So I have a huge list of blogs that I am reading on a daily basis (
http://www.google.com/reader) trying to maintain a long list and zero based unread posts on a weekly basis. Well I’ve crafted some tricks to overcome the huge amount of posts and the tradeoff between subscribing to everything and having the amount of posts that a human-working-being can read, but this is for a different post.

Goal: 30 minutes a day is a good place to start with and 2 hours during the weekend, so all in all 4.5 – 5 hours a week is the time for yourself to learn from others
Tip: 2 tools that will make your reading experience better during this the day -

Rule #2 – View technical sessions\videos
I must admit, I am not a big fan of podcasts, don’t know why, maybe because of all the sponsors and chit chats (and the geeky jokes) during those sessions, but I really like watching live sessions\video.

Goal: 1 video per week.
Tip: Keep in mind that sometimes you will need to start 2-3 videos and turn them off. try to find at least one that you can watch till the end. I like to summarize it as well and save a reference

Rule #3 – after school curriculum
The logic here is actually the same reason that your parents sent you to learn physics, chess, judo, or whatever outdoor activity right after school - Here you are responsible for yourself. We have many options but as I see it you should at least choose 1 to push at every single minute.

  • Participate in open source – choose an open source project you feel connected to or you think you want to learn from. Being an active part in Open Source Community can help you learn a lot from others – e.g: how they work, standards, tools, collaboration and code-reviews by people that you will probably never work with.
  • Deep Dive into the details in writing your own solution for existing framework – trying to write on your own a replacement for nihberante (or at least part of it) or write your own linq-implementation or implement your own map-reduce instead of just using it can help you a lot ot understand the underlying implementation.
  • Learn a new framework\language – you can start with huge projects like: starting to use linux, perl, F# or smaller projects like use hadoop or lucene.

Each one of the three has its own benefits and you should try to play with all of them, but all of them are about practicing your coding-skills. Most of the people that read a lot, don't find enough time to practice their coding skills, which IMO, might be a mistake.


Goal: have at least two projects for the next year

Tip: as a developer we tend to jump from idea to idea, project to project, committing one file in nhibernate, then learning mvc, reading about lucene, installing mongo, but not playing with them for more than few hours\days,

try to set yourself a goal for 3-6 months to play with it, I guess that all your time is during the weekend and nights, so you will need enough time to learn and play with it to learn whether it is good or not.

Bonus: If you are working in a company with more than 5-10 developers I suggest you track others commits on a daily basis. It isn't going to be easy, but tracking commits and sending your notes (online) to others might help you improve your skills a lot (reading more code than you ever thought you can and letting others know what you think and sometimes argue about it)


Rule #4: Teach others:
Try to explain what you learn to others. The major problem in learning for yourself or reading alone is that you might not be able to get real world feedback about what you’ve learned,
Same idea as
rubber ducking or pair-programming – sharing with more will force you to improve the knowledge that you already have. Presenting to others will make you ask more questions and dig a bit more.
Setting a day for a presentation will also help you to make your goals public so others will anticipate it, and that won’t let you run away in the middle of something.

Goal: Set Two lectures for the next year
Tip: combine the two rules #3 + #4 to lecture on the subjects that you choose to deep dive. So if you decided to learn a bit more about F# - set yourself a meeting till the end of the period, this is some kind of a milestone for your knowledge.
Bonus: Write a blog, or share your weekly\monthly learning with a group of people – again for the same purpose. It will give you smaller milestones on your way to becoming an expert

Rule #5: read books
Don’t take shortcuts, IMO, reading only blogs might take you into the final point\decisions of someone else’s journey. While it can be good, I prefer reading the raw data.

Goal: 4 books a year
Clean Code, Pragmatic Programmer, Applying Domain Driven Design, Framework Design Guidelines in .net 
You can Track my reading list
here and here.

Would love to hear from you – what do you think about those Goals\Tips?

Monday, December 31, 2012 2:23:00 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] - Trackback
Leadership | Software Development | Agile | Lean

# Wednesday, February 16, 2011

Nir just finished coding his new module, simple read-only entrance page that renders grid of products with its name underneath, each name links to the relevant product page.
This feature was deployed a week later. After deploying to production we find out a new bug that wasn’t discover during QA phase.
Our team has 5 developers which each of them committed at least one feature for this release. After cursing and blaming I scanned the latest release notes to find the possible features we just deployed I’ve found out that the bug should be part of Nir’s implementation. of course that Nir already started his next feature and need to have an expensive context-switch to resolve this issue. Additional overhead which can’t be avoided in order to understand whether we need to deploy the hotfix right away or we can wait for the next version, not talking about synching between other bug-fixes.

Sounds familiar? Do you release versions too? Try thinking of releasing features.
Think about it, release the feature when it is DONE. don’t wait for others.


   Releasing all features in one planned ahead release, check feature #5 – that will need to be queued till the next release\train


     Releasing a feature when it is done. feature #5 will be released when it is ready – no need to wait for the next train


So, Putting the technical details aside and the context switch we already explained, try to think about your product managers – they’re going to love you.

                 Read more about ideas-code-data 

In Delver we started our journey to continuously deploy to production. Read more here.

Meet Nir Altmark, a good friend of mine and a teammate at Delver he is a gifted developer who knows how to get things Done.
Nir just published two new posts about releasing faster and Building confidence between QA and Dev – well written. Read them to have a better understanding about this process.

Wednesday, February 16, 2011 6:33:27 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] - Trackback
continuous deployment | Software Development | Lean

<July 2015>

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2015
Shani Raba
Sign In
Total Posts: 146
This Year: 0
This Month: 0
This Week: 0
Comments: 97
Cool Stuff
Add to Technorati Favorites
Pick a theme:
All Content © 2015, Shani Raba
DasBlog theme 'Business' created by Christoph De Baene (delarou)