You have a tried and tested approach for solving a knotty problem; however, getting organizational buy-in feels like pulling teeth. You’ve tried cajoling, begging, storming, bargaining and more to no avail. Nothing seems to work; you’re frustrated and thinking of quitting.
How do you get a brand new team to become productive within three months? This post describes the lessons and techniques from rapidly ramping up these teams. These tips should help new members become productive within 12 weeks.
This post describes a simple framework for evaluating career choices along three dimensions and helps you to choose what is most important to you.
You have two choices when new challenges emerge: Offer several reasons why things wouldn't workSeek growth opportunities from the challenge Let's talk about the latter option. Scenario Your team dances through complex rituals every month before it can successfully deploy a big batch of changes. Engineers dread the drain on developer productivity and attendant customer … Continue reading Taking on scary challenges
Excuses are easy, take ownership and drive for results
Are you working on the right problems? If no, then focus all your energies on identifying the right problem with the biggest impact.
How do you drive change across difficult environments? For example, presenting radical new ideas to an unreceptive audience or collaborating with parties with opposing interests
How to brilliantly deliver on seemingly impossible projects
That is the question I like to ask nowadays at the beginning of anything: a sprint, a project or a book.
Tips for running services at scale with minimal toil
There is more to software development than writing code. This post describes three of the most oft-repeated tasks I have been asked over the years. These are not strictly programming tasks but help magnify the impact.
Do you want to sleep well at night?
Late in 2016, I made a conscious decision to become a full stack engineer. It was a tough decision for me because it meant a career reset and came with some risk. I would also have to learn a lot and fast too to be an effective contributor.
This post discusses the traits of the excellent engineers I have had the opportunity to work with over the years.
I recently transitioned into a full-stack role - I wanted to stretch myself and step out of my comfort zone. The biggest challenge was my struggle to quell the quite nagging voice in my mind screaming 'impostor!'.
Nearly everyone goes through moments wherein they doubt their capabilities.
Looking back on my time as a developer, there are a lot of things I would have avoided doing if I had as much knowledge and maturity as I did now.
I try to read a lot of books. Over the years, my 'taste' for books has been refined and some of my criteria are listed below.
I have made a couple of mistakes over the years and wanted to share those pitfalls so upcoming programmers know what to avoid and what works.
Looking back, I have learnt a couple of lessons the hard way and wanted to share some of these so that other engineers know what to avoid.
Engineers need to estimate system performance and simulate real-life scenarios. For most engineering fields, there are rich banks of proven theories and mathematical relations to rely upon. Unfortunately, software engineering - the new kid on the block - has a few rigorous rules, most times we rely on heuristics and handed-down wisdom.
Effectiveness, (noun) : the degree to which something is successful in producing a desired result; success.
Programmers have to love their craft and put their best into making it stand out.
1. Deliver when you commit It is extremely bad for your reputation to fail to meet up to your words; if you can't deliver, please say no or find an alternative way out. How would you feel if an artisan disappoints you for no good reason? I bet you'll probably never do business with them again. … Continue reading Becoming a Professional Programmer
A collection of resources for staying up-to-date in the industry