Category Archives: Programming

Can I take programming as life time career choice?

Published May 23, 2015 8:01 pm

In the past posts, I had gone over taking programming as career choice, taking a lead role and switching to IC role after taking a lead role. If you are a techno manager, you will certainly come across a career junction – to make a choice whether to pick a general mgmt direction or continue to remain a techno manager or IC role. I have been through this whether I should/can continue to code through out my career?

Wouldn’t my gray cells give up after some time since programming so much depends on your cognitive power? Would I generate enough value compared to my years of experience? Would I work against the probability for having a successful career? I won’t be surprised if many of us go through such questions when faced through this choice.

Do doctor think about taking its practice as life-long career? Do painter think about taking painting as life long career? In fact, well known painters are known for painting till quite late in their lives. then, Why as a programmer I face this question. I do think there is little bit of perception of this as low-end work – the leaf node work. Visions are built at top & translated into reality by engineering. It is like architects make the building drawings & buildings are built by the workers laying the bricks etc. but isn’t that true for any other profession? Not every painter is known for his work. neither every doctor. Still many of them can have a long satisfying career.

Programming alone does not cut it. If I just good at coding and keep doing that. It is likely that I hit a saturation point and that might be ok for many of us. As long as we recognize it and content with it. In that case, I am still good at what I am doing; I do a good job at it; I am still known within my group, organization, company. It gives me a work identity to be content with and I continue doing what I like.

I like more creative freedom. I like to paint on a bigger canvas with absolute creative freedom. That is where some of us take a plunge into envisioning the product & building it. Entrepreneur + programming is a good combination. You can see a gap & have ability to build an awesome product addressing it plus you love doing it! To begin with, we might fail couple of times. Did we born as exemplary programmers? we didn’t. Then, building a right product addressing right audience may require few attempts. It is hard especially when you take it later in your career when opportunity loss is higher. If it can be done with finances flowing from other streams, it’s a good combination to begin with.

but there is a deadly combination. Entrepreneur + programming + people – if you can have a close network of people – who are your fellow product programmers – who aspire to dream about and bring to life awesome products  and you all get along well at creative & value system level. It is the best and the deadly combination. It is the power of many hands, openness for creativity and alignment of value system for trail-blazing speed.

What is the value system alignment? Are you in it for money? Are you in it for your creative freedom or building something useful? If there is alignment – there is less friction, more power of diversity, power of more minds & hands.  1 + 1 can be 11 or it can also be zero or -1 if both 1s are chasing in opposite directions. In general, I am of the opinion that smaller organization are good for building new things from scratch & bigger organization are better for sustenance & scaling up an established product at smaller scale.

Is the path easy? No. No path is easy anyway. You do go through your set of nightmares. but you grow with them. Dealing with failures (or call it learning steps) is a separate post by itself. Once you board the entrepreneur track – it doesn’t mean you don’t ever go back to a job. Entrepreneur in spirit are the flexible people who are chasing their present goals. It is worthwhile to take a job when you go through your learning curve – to make a living and also learn new things.

What about architect roles? In general, good architects are also good engineering managers. As long term career choice, I still consider this path as techno manager. Programming as life long career choice means you love programming – like a painter love painting. Such people typically hop between IC (individual contributor), lead (first level manager aka M1), engineering manager/director (M2), architect etc. along the career just to taste little bit for everything but wherever they are – they love their art (code). They also like working with people; in few roles, they may not right performance reviews but still love working with a team and team rally with them.

Did I cover all the combinations? certainly not. I have seen few unique examples personally but they are rare. E.g. T Roy @ codemachine.com, Mark Russinovich @ sysinternals . They are exemplary in their art and excel in their niche. Needless to say there are many such personalities who have created their own unique example.

In sum total, programming alone does not cut it as a life long career. A techno manager can be a satisfying career if I keep up my good work, keep learning, realize myself & be content with it instead of getting caught up in rat race. Programming + (entrepreneur + people | more) can certainly create awesomeness. Isn’t awesomeness little rare? Still strive for it!

sd vs git commands

Published February 21, 2015 10:16 am

If you ever worked at Microsoft, you would have used the source depot command line tool sd.exe. Prior to tfs, this is the primary source depot tool used within Microsoft including windows team. Although, it used one more layer of top of it to enable branching across multiple source depot servers. Outside Microsoft, you get to use tfs using tf command line or using visual studio integrated UI. git is prevalent at other places.

gitA programmer is interested in code everywhere & hence, getting familiar with git is important. Hence, I just started by skimming the Pro git book & taking github tutorial. Getting comfortable with any tool takes little time and also you learn by mapping your old concepts to the new tools.

Here are my notes as I am going through this::

sd command/conceptgit command/concept
sd is typical source depot with a central repository & local client mapping. There isn't distributed repositories (although it has concept of proxy servers). For most of the commands, source depot server need to be available including branching, merging etc.git comes with local repository & remote repository. This is key high level difference which then translates into differences in the individual commands.
enlistment
- local copy of the files		Working directory
sd client - set server/local path mappings
sd sync - sync local copy		git checkout - update working directory with files from required branch
NA. There is only central repository.git remote - setup mapping with remote repositories.
NA. There is only central repository.git push -- publish changes
git pull -- fetches changes
to/from remote repository.
change list - a set of files that can be committed to server. multiple change lists can be maintained in the enlistment.staging directory.
files need to be staged prior to commit.
sd add -- add files
sd edit -- edit files
to change list		git add - add files
to staging area
sd revert - reverts changes git reset - remove file from staging area
git checkout - reset contents of file to last checked in version
sd delete -- delete file
to change list		git rm - delete file
to stage area
sd submit -- submit change list to servergit commit -- submit changes in staging area to local repository
sd branch -- create a branchgit branch -- create a branch
sd integrate -- to merge changes forward/backward to/from child branches. called forward & reverse integrate.
sd resolve - merge changes		git merge -- merge changes from child branch or remote repository,

* These notes are kind of high level mappings & are meant for me to jump start; get to more details along the way.

 

Taking an IC role after being in programmer lead role

Published February 4, 2014 3:10 pm

In the last post, we talked about taking a programmer lead role. Once you are in a programmer lead role for couple of years, you may feel the urge to go back to your roots; that is taking IC (individual contributor) role. The reasons can vary:

  1. Lost touch of code because of not coding enough in lead role.
  2. Need to update on new frameworks/concepts since software development goes through paradigm shift 1-2 times in a decade typically.
  3. Need to upgrade my design/architectural/coding skills to next level.
  4. Find the lead role stressful to be responsible for something that you don’t do yourself.
  5. lead role feels like glorified cleric job to divide work and manage delivery.
  6. work-life balance is disrupted. I come the first and leave the last. Work never seems to end.
  7. Writing and delivering people reviews is stressful.
  8. Feel like sandwiched between management and team.
  9. Team health metrics for you are not favoring you in lead role.
  10. For personal reasons, you can’t take up more responsible role for a period.

As far as I can think, reasons typically fall around this. They can be categorized into the following:

  1. Need to upgrade technical skills
  2. Need skills to cope up with lead role
  3. others

For (1) and (2) – there is choice to stay with lead role or go to IC role. For (3) – it is like you have to simply go back to IC role; there is not a choice as such. For example, I have family emergency for a year and need to scope down on work responsibilities. In such case, you and your manager need to work out if there can be different role for you interim. Typically a lead role does not fit part time.

Need to upgrade technical skills

This might be quite stressful if you think your tech skills are rusting and you are struggling to find time to tune them in your role. Lead role has multi-tasking as given and high chance of getting randomized at least in the beginning. Finding your uninterrupted few hours to up your tech skills is a struggle at times. Soon you are getting concerned about it if not losing sleep over it. A techno-manager discipline focused role (dev/test) requires one to be up to date in his tech skills to be respected and deliver business.

There can be many solution for this. Prevention is the best approach. In this approach, you step into lead role – as we talked in the last post – only when you consider yourself ace developer. That means to start with, you have ace tech skills. If not, this approach won’t work for you. Now that you have a good tech skills to start with and say beginner managerial skills, focus hard on your team skills like setting team member goals, negotiation, impact and influence, mentoring and career development, giving feedback, leadership, writing and delivering people performance reviews. code and design reviews – to impart your good practices to team members and add your contribution to project technical deliverables. Each of these skills require their own post to go into detail but we will talk that another day.  First 1-2 years is key when making a transition to lead role – to ace these skills and to graduate out of beginner manager. Feeling uncomfortable at the beginning is being human. but sign of graduation is that you start feeling comfortable with these. e.g. you manage a feedback session as you would write code.

It is good to make time to write code themselves. Start with 3 team members and add slowly. As you get comfortable with managing, you find more time and use it to write code (that implicitly means you get to design also). This does not mean you will not get outdated. but it will take longer and reason to update yourself will be little different in this scenario.

As you move from beginner developer to advanced developer  on IC track, you get to solve more involved technical problems that requires 100%+ focus from a person. As a lead, it is hard to take up such assignments on your plate without stretching++ yourself. For example – taking up performance tuning for a component, security review of the project, prototyping to boot strap a new project. In such cases, it is wise to switch to advanced developer (IC role) for a period. After such project, you are a better lead. People skills don’t rust easily and stay with you longer.

Doing back and forth between IC, lead and M2 role in a discipline is healthy. It builds perspective and keeps you grounded. It requires commitment, hard work, patience and little bit of courage.

Need skills to cope up with lead role

In IC role, you used to do things. In lead role, your b**t is on line for team deliverable and requires you to get things done. It comes with additional ambiguity. First of all, it will need us to be comfortable with higher ambiguity in the system. For example: now it is not only about this-code-does-not-work but about work does not fit schedule, unplanned leave in team etc. Need to plan the work; stretching to meet target won’t work without planning first. After the planning, accept the ambiguity, and deal with it when it comes. Know what you can get done, have some level of buffer, under commit and over deliver vs over commit and under deliver.  Beyond that – Analysis paralysis or scheduling the unknowns won’t work. Basic principles like manage long poles in schedule, load balance, creating backup for team members, schedule risks first so that you have time to react, schedule prototype to iron out technical unknowns before committing to schedule if there is lot of unknowns, prioritize, cut features or buy more time, will help.

Communication is key to team work and deliverables. This is key to pass the right expectation to team. If you have steep target and soft in communicating the urgency – you will feel being sandwiched between the team and your management. It is like management want urgent deliverables and team is conducting business as usual.

Delegation at right level is key. e.g. You can’t delegate division of work and resolving dependencies to your developers. then, you don’t know how deliverables will line up to target date. At the same time – you can’t keep the work of team members with you. You can’t clone yourself and hence, you can only end up doing mornings and late evenings for the unscheduled work – to meet team deadlines. Again, this topic requires much more than one para. but you get the point right?

Change is always hard. Don’t look it through a wrong lenses in the beginning. This will lead to thinking that your work does not help add any value. You are simply a glorified cleric dividing the work among team members. You value addition is through code and design reviews. Further, you can generate able trained developers for the organization. An able dev lead is a factory that generates ace developers. Needless to say – don’t stop coding yourself.

Writing people reviews may come as shocker for some at the beginning. Be objective. Focus on the behavior, results rather than individual. Doing frequent feedback will help not have one marathon annual review. Write detailed feedback. Do one review a day. Keep 1-2 weeks of schedule around annual review to be able to reflect and do good home work before delivering the review.

Personal connection with team is key have good team health. It’s like making time to laugh together by going for a lunch or dinner on an occasion. Across the table, you talk anything from cricket, movies, music to physics. You get to connect as team. You open up to each other to discuss things. Every individual is a human apart from developer. A manager role is to marry business to people. You need to know their aspiration, and constraints; guide, and mentor them. One need to see how work is adding to his skills and growth apart from delivering business. These are basics of team health. Again – this requires much more discussion than one para. Nevertheless, one need to be little more than a nerd – a little social being to build team health.

In summary, moving between IC, lead and M2 (second level manager) roles is healthy to build perspective and good to consider doing this. Lead/manager role requires honing people/team skills which needs attention and action when taking the role first time. Good luck to you to be an ace IC, lead and M2 . Keep rocking! Next time – we talk about whether to take a programmer role for life time career?

 

To take or not to take a programmer lead or manager role

Published December 4, 2013 1:02 pm

In the last post, I tried to go over natural traits of a programmer and see whether one has natural inclination to be a programmer? As a programmer, you come at a crossroad – typically in 1-5 years – where you have to decide whether you want to lead a team? It exposes itself as an opportunity or you come across it when thinking about your career growth. In my case, it came as an opportunity within 3rd year of the career as programmer.

It is human to feel uncomfortable with the change at the onset. I did not know much theory about change mgmt. then. Later, I had come across theory about how people respond to change. Closest picture I could find on net about that is here and here. Your response to the expected change might be inline with the curve in the picture. That is ok but there is more to this.

There are 3 parties involved when you take up lead role – you, work and team. As long as you work as a programmer (individual contributor aka IC), there are only two parties involved – you and work. This change is key to note. There was so much to learn when I boarded my first job. My key focus at that time was to grasp, learn at exponential rate. In a way, focus is so much on you and what you produce; your excellence. The other parameter – team – brings team deliverables, team performance and career mgmt. to name a few items. Like it or not – they are equally important if not more – in your role as lead. (There are many titles that are used for this – like dev lead, project manager, test lead, qa lead. I will keep it as lead in the post.). It is good to come to terms with this. This will impact how much time (at the least in the short term) you can spend programming/researching yourself. Typically, you get to spend good 50% time or more with other items – to begin with.

Lead role typically comes with career growth though it may not always be the case. There are companies where there is a parallel career path for IC and manager. That is there is no need to be a lead – only for growth. Also in this role, supporting people through their career growth generates intangible job satisfaction. It is very key to know your intention. That is whether you are interested in the lead role for career growth or supporting people or both. If for career growth only or mostly, it may not work well. It will be hard to grow as a manager without being genuinely interested in people, and you may finding it taxing. Well, we all see during our career – good managers and bad managers. How come the bad manager could grow so much in that case? You are right. Let me put it other way – you might not make a great manager although you could still grow based on other parameters like – taking scaled up responsibility and deliverables. In nutshell, it will always help – to have genuine interest in the growth of the people – as manager. It may not stop you from taking a manager role.

First level manager are better accepted as techno managers. Are you at a stage where you have something to impart to the fellow team members? Some of these questions might help know that objectively?

  1. Do you ace your deliverables in the project?
  2. Are you considered a go to person for some of the component(s) in the project?
  3. Have you successfully on-boarded/mentored new joiners in the project?
  4. Do you produce code as per the standards of the group – if not help improve it?
  5. Do you debug difficult technical bugs and issues for the project?
  6. Have you handled external communications (technical or otherwise) sometimes?
  7. Have you negotiated your schedule/deliverables with your manager?
  8. Have you debated technical designs/issues with fellow team members?

Some of these question will help answer objectively whether your team can look up to you – to learn & lead and whether you have basic skills to lead a team. I am not going through the laundry list of skills here to avoid going by the book. Your organization might have listed the management skills formally and it won’t harm to skim through them.

If these parameters are aligned – that is 1) you are ok juggling – you, work and team – priorities and its impact on your daily working pattern 2) you are interested in people n their career 3) you ace your art as IC and have basic skills required to be first level manager, it won’t harm to take your first plunge into leading a group of programmers. Even if you are not be able to make an long term choice – to take IC vs lead track now, experiences from lead role will help hone up new skills that compliment technical skills for your career growth. For example: it helps – to be a better communicator, to be able to influence fellow team members, have empathy and to be little more team-social – as IC.

If you have made a choice to take up lead role, congratulations in your new role and best wishes! After few more years into your lead role, you may face more choices. For example: shall I go back to an IC role, is moving between IC and lead roles ok, Shall I take up M2 role, Can I take up programmer role as life time career path? Let’s pick up one of these in the next post.

To be or not to be a programmer?

Published December 2, 2013 3:44 pm

Do you have appetite to be a programmer? Do you relish programming? Can programming be a life time career for you? These might be some of the questions –  a programmer may ask himself at different stages in his career. There is no definitive formula – I have seen – to get a yes/no answer. I am also somewhere in the mix, and can share some of my experience.

When I was graduating from the college in comp sc., I got first introduction to programming. As part of the first semester to learn Pascal, I got the first kick for the programming, and found like minded classmates; among us we gave competition and positive pressure to keep leaping and stay one semester ahead. We were always one semester ahead for the programming courses. That time – I did not ask myself – whether I have appetite for programming or whether I relish programming – but I simply found my appetite for it and relished it. Looking back, I can see few things that stand out if one has appetite for programming:

  1. Getting the output after few-hours of hard work – putting the code – gives immense satisfaction.
  2. You are impatient to put all details on paper or a document. You itch to code it and see it working. You would draw/put a rough sketch/skeleton pseudo code and then, get to code. Iteratively – add functionality and see it working.
  3. You have more inclination to mathematical problems than theoretical subjects like History. Because you find it intuitive to score well in logical subjects. Once the concept is learnt, that is it; no mugging required.
  4. You itch to learn new languages. but time constraints keep you away if at all. You definitively take up assignments outside the course – out of your interest.
  5. You wish if you knew all apis by heart – that way you can code fast. You learn the shortcuts of the code editors. You learn typing if you don’t know already;)
  6. You care for good design but you are averse to any process overheads that let you not produce code. You certainly don’t gel well with process-first managers.
  7. You take bugs in code personally and constantly challenge yourself to produce bug free code. I have heard Sachin saying once that he thinks over after each match – the reason he got out. You would think every time you fix a bug – what would have saved that bug.
  8. Code is your art. You strive to get better at it. You are naturally inclined to pick good treats from well written code. You hate badly written code and want to eliminate it. You always carry your code with you on your external disk, pen drive, cd etc. unless the IP rights prohibit you.
  9. You strive to get working code daily if not every hour. You can sit at stretch for 4-10hrs daily coding.
  10. You rewrite your own code until it matches your criterion of quality.
  11. You like being in code than in ppts.

If you see some of these traits, it is likely you have natural flair for being a programmer. It is very likely that you have already embarked on it since it kind of comes natural. The real questions start popping years later when 1) one is faced first time with the choice of taking up lead/manager role and later, when 2) he/she needs to decide whether this can be a career choice for life time. (1) is easier than (2). Let’s catch up on this in the next post.