Talking with Tech Leads

Talking with Tech Leads is a book by Patrick Kua for Tech Leads from Tech Leads.

What is a Tech Lead?

Patrick defines a Tech Lead as follows:

A leader, responsible for a development team, who spends at least 30 per cent of their time writing code with the team.

How Tech Leads provide value

Tech Leads provide value by:

  1. Helping developers code
  2. Collaborating with stakeholders outside the team
  3. Justifying coding in a sustainable way
  4. Communicating business priorities

Prioritising team over code

Tech Leads prioritise team focus and harmony over writing code. This can be tricky when the technical aspects of the job are their favourite.

Tech Leads allow developers to make mistakes as failure is a natural part of the learning process. They should provide feedback at the right time to maximise learning, while  limiting the impact of failures.

Being objective and focussed

Tech Leads choose their words carefully as they know that the team will watch, observe and judge every word and every action. They have to control their emotions and maintain objectivity.

Tech Leads focus on a few issues and let go of the rest to give them time to sort themselves out.

The 4 Best Coding Principles in “Coders at Work”

Coders at Work documents conversations with fifteen great programmers. These four coding principles came up throughout the book as universal principles that are worth adopting:

Principle 1 – Keep Code Simple

Coding as simply as possible is normally enough to solve most problems. Programs ought to make sense, there are very few inherently hard problems.

When you have a hard problem, recognize that there is probably a known solution. Once implemented, use comments to state the purpose and reference source algorithms. Always protect difficult to understand code with tests and remember it is easier to optimize correct code than to correct optimized code.

Readability of code is now first priority, judge programs by their ability to communicate with the human reader. Use a dictionary to find appropriate language. Think of programming as writing a story to express a concept to a very tired person with limited vocabulary.

Principle 2 – Think About APIs

Consider interfaces first and identify the common methods, RPCs or queries. With an API, when in doubt, leave it out.

You cannot get an API right until you have practised using it externally. Use test-first programming and refactor the APIs instead of refactoring the implementation code underneath the APIs.

See Joshua Bloch’s How to Design a Good API and Why It Matters

Principle 3 – Deliver Valuable Work

Set up projects for immediate gratification, find the first piece of success that is achievable. Build team confidence with a clear understanding of the project and tasks required to achieve success. This includes understanding who the customers are.

Rewrites rarely support business objectives. Migrate to better languages but do not expect that they will give you a one order of magnitude improvement in productivity, reliability or simplicity.

Principle 4 – Debug with Focus

Use test-driven development, static analysis and code reviews.

We will always have bugs if we stretch our capabilities. The worst bugs are multithreaded ones. When you encounter a bug, think like a scientist and patiently change one thing at a time to understand the root cause of things.


3 Career Guidelines from The Pragmatic Programmer

The Pragmatic Programmer by Andrew Hunt provides practical suggestions on all aspects of software development.

Guideline 1 – Develop a Knowledge Portfolio

“An investment in knowledge always pays the best interest.” Benjamin Franklin

Programming is an intellectual activity and the value of a programmer is based on their knowledge portfolio. The portfolio must be built and maintained with regular investment and diversification:

  1. Read at least one technical book per quarter
  2. Learn a new programming language every year
  3. Keep up-to-date with emerging technologies

Local user groups are a good way to improve your knowledge portfolio and provide an environment to hear about career opportunities.

Guideline 2 – Communicate Well

Strong communication skills help programmers to build influence in an organization.

  • Choose when to communicate based on audience needs
  • Adjust your message to suit the level of understanding
  • Listen first, then respond

Use the WISDOM framework to target your presentations:

  1. What do you want them to learn?
  2. What is their Interest in what you’ve got to say?
  3. How Sophisticated are they?
  4. How much Detail do they want?
  5. Whom do you want to Own the information?
  6. How can you Motivate them to listen to you?

Guideline 3 – Pick the Right Tools

Tools amplify talent. Aim to:

  • Use a single editor well
  • Understand the command shell
  • Use source code control
  • Automate the build process

5 Technical Guidelines from The Pragmatic Programmer

The Pragmatic Programmer by Andrew Hunt provides practical suggestions on all aspects of software development.

Guideline 1 – Write Understandable Code

Code is read more times than it is written so spend time writing clean code with clear variable names. Add comments when it is necessary to explain why the code is written that way and the decisions behind the implementation.

Each software module should be responsible for a single aspect of the system. When software modules are written to act independently, the system can provide more combined functionality as a whole. A module should not delve into another module’s implementation (Law of Demeter). Ask for what you need directly instead of digging through the module hierarchy.

Guideline 2 – Refactor Early

Refactor early to prevent existing code dictating future code. Refactoring is a process that must be undertaken slowly, deliberately and carefully. Always take short deliberate steps and have good test coverage before you begin.

Refactor when there is:

  1. Duplication
  2. Nonorthogonal design
  3. Outdated knowledge
  4. Improve performance

Every piece of knowledge in a system should have a single authoritative representation (DRY principle). Developers will often duplicate code in the short term to ship faster, at the expense of duplicating effort to update that code in the future.

Guideline 3 – Expect Errors

Everyone writes bugs. Do not trust or expect yourself to write perfect software and do not blame third-party libraries for your mistakes.

When you find a bug, try not to panic and concentrate on fixing the problem. The best way to start fixing a bug is to make it reproducible. This will also tell you when it is fixed. If you feel stuck, explain the problem to someone else as the act of explaining often reveals the solution.

Try to fail early at the site of the problem. Errors should not leave the system in an inconsistent state, for instance charging a credit card but not processing an order.

Guideline 4 – Test from the Start

Projects with automated tests have a better chance of success. Accessible test code is an invaluable example of code use, with crucial benefit of alerting you of regressions as you make changes to the system.

Build testing into the software from the beginning. Test each piece of the project independently with unit tests, then together with integration tests. When you design a module or even a single routine you should design both its contract and the code to test that contract.

Guideline 5 – Use Configuration Files

Put abstractions in code and details in configuration files. Configuration files allow an application to be customized without recompilation. This is extremely important in critical live systems which need to dynamically reload metadata while running to prevent downtime. Another use-case is distributing the same core app to different clients and enabling features based on their specific configuration.

3 Project Guidelines from The Pragmatic Programmer

The Pragmatic Programmer by Andrew Hunt provides practical suggestions on all aspects of software development.

Guideline 1 – There are No Final Decisions

“It’s easier to ask for forgiveness than it is to get permission” Grace Hopper

There are no final decisions in software construction. Some requirements will turn out to be easy and some impossible. Product managers that ignore this fact will always be shocked when the future arrives and they are left wondering what went wrong.

Teams become less aligned on decisions when there are more people involved in the decision making process. Separating responsibilities between team members helps teams to make decisions faster.

Guideline 2 – Requirements Will Change

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to cut away.” Antoine de Saint-Exupéry

Recognize which requirements are long-lasting and which are short-term. Business policies like shipping freight every two weeks can change, but the fact that the system is about freight shipment will not. Document these changeable business policies away from the more generic requirement and recommend they are implemented as metadata or configuration in the final application.

Try not to be a slave to formal methods like UML because these methods often require additional explanation to both programmers implementing the specification and the end users buying the software. It is far better to iterate on a technical blog post that can be shared with both users and developers.

Guideline 3 – Estimate from Experience

Estimate to avoid surprises. The best estimate comes from someone who has already created a similar project. Take time with estimates instead of producing them off-the-top of your head.

A simple technique to improve your estimates is to:

  1. Break the software application into components
  2. Estimate the duration to create each component
  3. Compare the actual durations to the measured durations
  4. Use this knowledge to iterate your estimations

Anything critical or difficult should be first implemented as as prototype. This helps to reduce the cost for correcting design mistakes by analyzing and exposing risk at the start of a project.

The Art of Innovation – Part 3: Tips on Brainstorming

In The Art of Innovation, IDEO’s founder Tom Kelley writes his lessons in creativity from years of success through innovation. In this three-part series, I will take you through key takeaways from the book. This third part contains IDEO’s tips on brainstorming to enhance creativity.

7 Tips to Enhance Creativity

  • Act, sketch and mould physically, let the space of the room indicate the development of ideas (fill with paper)
  • Build and jump, let ideas flow then switch viewpoints or move laterally to keep the ideas coming
  • Defer judgement and criticism
  • Number ideas and go for quantity (100 ideas per hour)
  • Perform content related preparation and bring props for inspiration
  • Sharpen the focus outward, start with a well-defined customer need not on an organizational goal
  • Warm up by clearing the mind with a fast paced word game

5 Dangerous Habits

  • Asking experts in the target field gives depth not breadth
  • Bosses speaking first sets boundaries on communication
  • Disallowing silly ideas restricts wild, potentially successful, ideas
  • Forcing turns prevents ideas flowing naturally
  • Recording everything breaks the flow of the brainstorm, assign a scribe and keep the energy

The Art of Innovation – Part 2: Company Mindset

In The Art of Innovation, IDEO’s founder Tom Kelley writes his lessons in creativity from years of success through innovation. In this three-part series, I will take you through key takeaways from the book. This second part is about how IDEO helps companies to adapt their mindset to become more innovative.

Step 1 – Know the Future

Innovation happens by looking at what isn’t there —Jake Burton

Know the soon to be state of the art. Each industry has places where you make connections and hear about the latest products. No one gets ahead copying products that are already established.

Asking child-like questions of “Why?” and “Why not?” helps to prevent assumptions interfering when evaluating an opportunity. Learn from the people who break the rules, perhaps adapting an existing product to a new use-case. Watch people struggle with existing products in new environments.

Step 2 – Hire Great People

Pro-actively hire the intellectually curious. If you hire the right people, everything else will take care of itself.

People perform when they feel special and sometimes the best inspiration is not doing work. Everyone has a creative side but it requires training like any skill. The person who tails endlessly at his desk is unlikely to be the one hatching a great innovation.

When you are stuck on a tough decision or have a problem that you do not understand, talk to all the smart people who you know.

Step 3 – Office Environment

The best offices celebrate teamwork and a high people density makes the office pulse. Make desks movable and group project members together so that space is just for teamwork and not owned by a person or group.

Provide good food and encourage play to have constant off-site energy. There should be no need for a physical off-site because creativity should flow in the office. The workspace should communicate positivity to both employees and visitors.

Step 4 – Dropping Internal Barriers

The biggest barrier to innovation is company mindset. Senior managers must encourage employees to break rules and fail forward so that change is part of the culture.

Success has a tendency to cripple future product development. Sticking with an existing product range is safer but loses in the long run. Instead, build products fast and leapfrog other companies in the market.

The Art of Innovation – Part 1: Building Experiences

In The Art of Innovation, IDEO’s founder Tom Kelley writes his lessons in creativity from years of success through innovation. In this three part series, I will take you through key takeaways from the book. This first part is about how IDEO builds product experiences.

IDEO uses a Five Step Method. First Understand the market, client and technology. Then Observe for gaps in the market and difficulties that customers face. Visualize how a solution can solve these difficulties with roll plays, storyboards and prototypes. Evaluate this solution and refine over several prototypes. Implement and market the solution, turning it into a commercial product.

Step 1 – Design

Focus on verbs not nouns, and design experiences not products. Optimize the common case first and focus on the points where people interact with the product.

Create five designs in the first week and present these to the project stakeholders to request feedback. Use their comments to refine the initial designs before making a prototype.

Step 2 – Prototyping

Never go to a meeting without a prototype. —Dermis Boyle

The process of creating a prototype sparks innovation, which is crucial for success. The project course can be corrected earlier and more often. Pitch the product in stages as the it develops. First show a rough sketch, then a cheap foam model.

When presenting a product, a prototype is worth a thousand pictures, and each picture is worth a thousand words. Prototypes are harder to reject but still need a good performance to have impact. Make trailers for each visual prototype and combine them with a great entrance.

Step 3 – Refinement

Once you have the first version of a product, test it as if you had never seen it before. It should be easy to understand, aim for the simplicity of tear-open tissues.

Once customers start using products you need to refine them. Refinement is asking what you do not need in the product and then removing it. The second version of a product should be simpler than the first. Always beware of the feature creep that happens when real innovation stalls.

Many products can be improved when observed in action. Get observers with in-depth knowledge of the product to watch potential customers interacting with it.

Step 4 – Marketing

If you can’t make a t-shirt about it, maybe you don’t have a compelling story

The energy and effort put into marketing the product can be the difference between it being a hit or miss. Adoption can take forceful marketing. Transform the way you are perceived and become sanctioned by the market. Do not advertise failures because it can prevent market acceptance.

Where does the time go? Charting your daily routine

A question a lot of us mull over is “Where does the time go?” in our daily lives. I wanted to explore if there was an easy way to understand and improve our daily routines.

What’s the simplest visualisation?

The answer I thought of was a clock. I marked points around the clock with the start and end points of each daily activity. At this point the clock began to resemble a pie chart. I extended it to encompass the whole 24-hours of the work day, including sleep.

This is the clock I imagined:

Visual Day Basic

You can see at a glance the amount of time spent on each activity. In this example, work and sleep both occupy over two-thirds of the entire day. Only two hours were spent on hobbies, less than one-tenth of the day.

Can we add more detail?

To get more value and understanding, we need more information. At the moment, the above chart could apply to most of the population and it is not telling us much about the individual. Let’s see what happens when we take each segment of the previous graph and add another level of detail.

  1. ‘Work’ becomes ‘Programming’
  2. ‘Dinner’ is actually ‘Cooking’
  3. ‘Hobbies’ is split up into ‘Gym’ and ‘Side Project’

Visual Day

This has become much more interesting. You are starting to see a picture of the individual outside of work. This person spends most of the day programming but also has a keen interest in fitness and health.

You could split ‘Work’ up into its subcomponents too. This could be interesting if you wanted to compare roles or companies. On the other hand, most of us have less control over our working day, so other people would learn less about us as individuals.

Would it change over time?

We can compare the same person now and two years ago. Here are the charts:

Visual Day Two Year Comparison

Although work and sleep have stayed the same, the rest of the chart is very different:

  1. The entire day has shifted back by an hour (work starts at 9 am not 10 am)
  2. Eating out has been replaced by cooking
  3. The individual is performing less exercise overall, and has swapped running to gym
  4. There is less going out and more staying in

These observations are useful to see how your life is evolving. For instance, if learning Spanish is your number one goal, are you gradually increasing the amount of time you dedicate to it? If you are tired at work, have you changed your lifestyle to incorporate more sleep?

How would individuals differ?

Here are two work days from individuals in different jobs:

Visual Day Vocation Comparison

If the accountant wanted to adopt a healthier lifestyle, he could look at the chart of a healthier friend to identify changes he will need to make to reach his goal.

These could be:

  1. Reduce the amount of TV
  2. Replace shopping with cooking
  3. Increase the amount of sleep you get
  4. Commute by bicycle instead of by tube

Any conclusions?

I like the idea of representing your life on a clock. The clock concept answers the question “What do I do?” and “What does that person do?” It helps to highlight periods of time to reclaim from activities you do not want to do, so that you can reallocate this time to activities you do want to do. You could also measure how you are progressing by comparing the clock with a month ago.

The 2 Biggest Project Failures from Dreaming in Code

Dreaming in Code by Scott Rosenberg documents the failure of the Chandler software project.

Chandler aimed to provide flexible information management. It organised emails and other data sources into a central object store. Intelligent features similar to Lotus Agenda’s “automatic assignment” aimed to predict semantic meaning from text, like automatically recognising events to add to your calendar.

Failure 1: Not knowing what you are building

The hard thing about building software is deciding what to say, not saying it —Brooks

Chandler’s team did not agree on how to build key components. This uncertainty became pervasive and spread to more decisions. The team wanted ‘more concreteness’ but could not achieve it. In retrospect, Scott comments that success requires firm choices to limit a project’s scope. Programmers can thrive under these constraints because it simplifies the problem.

Failure 2: Communication breakdown

Management is about human beings. Its task is to make people capable of joint performance, to make their strengths effective and their weaknesses irrelevant —Peter Drucker

The teams working on Chandler had multiple groupware systems for tracking project progress and communicating internally. This caused staying in the loop to eat up much of the workday. Developers drowned in emails, bug reports and wiki pages.

People tried to solve the communication problems by adding more resources to check. The author describes how a “heroic” additional glossary of project definitions, made to solve ambiguities, was abandoned unread.

Advice for the future

Information systems provide value when they interact with humans. Our world of information is not perfect, and any program is subject to having to connect to our imperfect world. Because of this, programmers should concentrate on solving the user need, instead of making a perfect technical solution for an imperfect world.

Communicating abstractions unambiguously — from programmer to machine, from programmer to programmer, and from program to user — is the single most challenging demand of software development.

Nobody should start to undertake a large project, you should start with a small trivial project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it is likely is at that stage. Or, worse, you might be scared away by the sheer size of the work you envision. So start small and think about the details. —Linus Torvalds