Tuesday, July 15

Deliberate Practice (Part 2)

Table of Contents


 D

eliberate Practice In Software Development

The Case of the Test First Developer


So how do we deliberately practice in order to improve our programming skills?

I use the same principles that I use to improve my bass playing to improve the software I produce.

Overlooked Opportunities

I find that many developers focus too much on learning language and frameworks features. While a full understanding of the tools you are using is essential, if you simply stop there, you are missing so many opportunities for improvement. Implementation is only one phase in the software lifecycle, you should not neglect the other phases and within implementation itself there are so many dimensions that it is unlikely you will run out of things to improve even if you feel you know the implementation platform back to front.

On-the-job Learning

Within my normal work there are many opportunities to practice. To keep it fresh I will focus on different improvement goals each session. In one session I may focus on composability, in another readability in another testability. In one session I will identify and exact reusable components from existing code in another test whether a particular approach or design pattern will keep the design simple or if an alternative would be better. 

Feedback

Test first design is ideal for maximizing immediate feedback. Pair programming gives lots of potential for feedback if you take advantage of it. Code reviews are a great way of getting feedback, however so often programmers see it as an annoyance. Tightening the feedback loop by getting early feedback from testers or users can be helpful.


Learning by Teaching

Teaching others is helpful in improving your understanding of the material. Whether helping a teammate with a problem or teaching a workshop on a topic or presenting at a meetup, the need to break down what needs to be done into small easily understood steps can help your own understanding and help organize your existing knowledge.


Learning from the Pain Points

I used the need to document an existing internal API to help drive improvement to the API. For each section in the API I would ask how can I change the API so as to make this section of the documentation u6nnecessary. I ended up simplifying the API a great deal making it much easier to use.

Learning using Practice Problems

You can use code katas or code koans to help practice your programming skills and there are many sites that offer problems for you to practice (see below).  


More Information

Articles

Videos

Problems to Practice

  • Project Euler - Solve mathematical problems using programming skills
  • LeetCode - Solve coding challenges, competitions and mock interview
  • HackerRank - Offers a variety of different types of programming challenges
  • TopCoder - Solve algorithmic challenges within a time limit
  • Code Wars - Community submitted challenges and discussions
  • Code Chef - Community site with challenges, competitions and tutorials
  • CoderByte - Coding challenges and tutorials
  • Exercism - Coding challenges with assistance from mentors.
  • Sphere Online Judge - Coding challenges, competitions and discussions
  • Hacker Earth - programming challenges and  interview preparation

Programming Games

  • Codingame - program simple games then play them
  • RoboCode - program tank AIs and pit them against others
  • CodeCombat - write code to solve puzzles

Posted by at No comments:
Labels: , , ,

Monday, May 13

Pros and Cons of Imposter Syndrome (Part 2)

T

able of Contents


Pros

You are constantly striving for self improvement
You are motivated to overcome or mitigate your weaknesses


Cons

Internal Focus - Its not always about you

It’s important to start by focusing on yourself and the actions you can take. However, that’s not where your efforts should end.

After you’ve observed, listened, and adapted—perhaps by using short-term workarounds—you should also look for longer-term solutions. These often require changing your environment, going beyond your direct authority, and using influence and negotiation.


Seeking External Solutions and Validation - Other people don’t always have the answers

It’s good to ask for help, but you should also evaluate the advice you receive using an evidence-based approach.

There’s a lot of bad advice out there. Ask yourself: Is it working for them? and Will it work for me? Remember, people have different strengths and weaknesses—your mileage may vary.

Sometimes, watching what people actually do is more informative than listening to their explanations. Ideally, do both.

You know your problems best. That usually makes you the best person to come up with a solution. This doesn’t mean you must do everything alone. However, taking ownership of the process increases the chances that the final solution will work for you and reflect your needs.


Over complicating things - There is no secret sauce

There are tips and tricks of the trade, but they are not secret. Watch, listen, put in the work, and be patient—you will learn them.

Sometime the skills you need are ones you already know e.g. ones learned in kindergarten. Sometimes simple solutions work, after all the classics are classic for a reason.

For example, I found that the best way to improve my social skills was simply doing activities I enjoyed with people I liked. (Who knew? My mother did.)

Impatience - Fools rush in

Everything doesn’t have to be fixed right this minute. As long as you are improving, and as long as you have a plan or a strategy for moving forward, that is enough.

Focusing on one area of improvement at a time is usually best.

Watch, listen, plan—then leap.

Boom and Bust - Slow and steady wins the race

Using a tight deadline to motivate yourself to complete a task that you lack confidence in, (or your instincts are warning you against) can sometimes help. However it can also lead to

  • Increased risk of failure,
  • More errors, 
  • Burnout, 
  • Lost opportunities.

Just powering through is not always the answer. If there is something blocking or interfering with your success, you should do something about it.

If your instincts are warning you against doing something, listen to your instincts. What your being asked to do may be 

  • Counter productive
  • Could be achieved in a simpler way           
  • Could be achieved in a way that is a more natural fit to your strengths and talents.

Working longer hours to compensate for perceived weaknesses can lead to burnout. It also doesn’t solve the real issue. Remember: Productivity means achieving more in the same amount of time—not the same by working longer.

Monitor and manage your stress levels and your general health.

Monitor and manage your stress and health. Sacrificing long-term capacity for short-term gains is rarely a winning strategy.


Analysis Paralysis 

Perfect is the enemy of the good. Even a wrong answer gives you a starting point to find the right one.

Learn to recognize when you’re spinning your wheels—and ask for help.

Not Speaking up

If problems are not discussed, they are unlikely to be resolved.

Avoiding Challenging Situations

You may avoid tasks where you might shine, due to lack of confidence. This can be damaging to both you, and your team as your potential contribution is lost.


Catastrophising - the sky is falling

DON’T PANIC 

Take a deep breath

Talk to your co-workers about your concerns. Ask for help.

Mitigate risks where the benefits out weigh the costs. 

Also consider: Are there opportunities hidden within the threats?

Focusing on shoring up weaknesses instead of playing to strengths

People work in teams for a reason. In effective teams, members cover each other’s weaknesses and amplify each other’s strengths.

That means you can—and should—delegate tasks to those better suited for them. Focus your energy on tasks where you have an advantage.


Conclusion

While imposter syndrome can drive personal growth and self-awareness, the downsides often outweigh the benefits.


Resources

Books

All I Really Need to Know I Learned in Kindergarten

Related Posts

Posted by at No comments:

Reasons for imposter Syndrome (Part 1)

T

able of Contents



Triggers

  • Being outside your comfort zone or trying something new
  • Lacking psychological safety and feeling unable to show vulnerability
  • Being haunted by past trauma and having learned the wrong lessons from previous experiences

New Role

If you’re nervous about diving into something new check out my onboardee’s checklist.



Constant Change

One of the challenges of working in the software industry is the need for constant learning. There is always new languages, new platforms, new frameworks and new subject matter domains with new jargon. Even if you stick with the same technologies and the same industry, the technologies release new versions and the industry evolves as the environment changes. You are always doing things you have never done before. You are continually pushed outside of your comfort zone.


Fake It Til You Make It.

We are told it is better to remain silent and be thought a fool than to speak and remove all doubt. This is baked straight into our school system. If we struggle then we are suppose to just work harder and bulldoze are way through.

However keeping quiet, means the you do not ask for help that you need or warn of problems that you notice. You may be setting yourself up for failure as underlying issues are not addressed and therefore worsen over time, leading to an eventual reckoning.


Sometimes You Aren't Safe.

Unfortunately sometimes you are not imagining it. You feel unsafe because your work environment is in fact not safe.

In which case you need to change your workplace or change your workplace. Don’t let it slide, your workplace culture is unlikely to improve by itself. A bad culture is stressful and counterproductive. Your team, your project and the company itself is more likely to fail, as problems do not get addressed, as it is unsafe to admit that they even exist.

The unfortunate habit that some people have of asking questions that they make clear only have one acceptable answer or showing no curiosity in a different viewpoint. This kills honest communication.


Past Trauma

I once mentored a colleague on how to present technical changes in terms of business value. They were hesitant to bring up certain points because of harsh feedback they'd received in the past.

I pointed out that that was a different company, different workplace culture, different manager and they had not used a strategy of emphasising business benefits.

Sometimes we overgeneralise feedback and the wrong lessons are learned. A cat that has been burnt will not sit on a hot stove again, but neither will they sit on a cold one.

 

The Effects of Imposter Syndrome

This is increased stress and erosion of confidence.

Stress affects productivity and learning in a U-shaped pattern:

  • Too little stress leads to complacency.

  • Too much stress causes panic, paralysis, and unproductive behavior.

Some people see impostor syndrome as helpful when it pushes them out of complacency and into a state of motivating eustress. Stepping outside your comfort zone can be an opportunity for growth.

Others highlight its harmful effects when it moves beyond motivating eustress into debilitating distress.

Conclusion

When lack of confidence is warranted it can lead to avoidance of risky or dangerous behaviour. And can motivate people to ask for help.

When lack of confidence is not warranted it can lead to avoidance of opportunities and the very experiences and practices that can improve those abilities. It can motivate people to hide the fact that they need help.


Resources

Related Posts



Posted by at No comments:

Thursday, July 27

The Onboardee’s Checklist

Y

ou’re starting a new job at a new company. You don’t know their internal processes or culture yet, and your role may be different from what you’ve done before.

You do have some information from the interview, but the reality of a job often doesn’t match the job description. Even if the interviewer previously held your position, day-to-day tasks are often glossed over in favor of more memorable, less frequent events.


Build Your Own Checklist

When you feel like you know nothing, it’s hard to make a plan. Every company is different, right? True—but you do have past experience to draw on.


If you’ve ever joined a new team, learned a new skill, or started a new activity, you’ve seen patterns emerge. Those patterns can form the basis of your personal onboarding checklist.

Here’s my checklist to get you started:

  • Know your go-to people – Who can help you when you’re stuck?
  • Map your resources – What tools, documents, and systems do you have access to?
  • Spot the risks early – What can go wrong? How will you know, and what’s your first response?
  • Understand communication norms – Email, chat, meetings—what’s preferred?
  • Notice process pain points – What’s broken, and what’s been patched over for too long?
  • Identify neglected work – Is there an unowned responsibility quietly gathering dust?

Remember: your weakness is that you know nothing—and your strength is also that you know nothing. A fresh perspective can spot issues veterans overlook.


It is common to feel overwhelmed. If you’re unsure how to ask a question, jot down your confusion. Then, once someone’s explained, revisit that spot and ask for clarity.


Make the Most of Onboarding

Document your onboarding experience—especially what’s missing or wrong. It will help the next person in your role and may highlight gaps for your team.

When reviewing tutorials or documentation:

  • Follow them step-by-step.

  • Note unclear instructions, unnecessary detail, or missing steps.

  • Suggest simplifying overly long guides by focusing on defaults for common cases.

Many tutorials suffer from the curse of knowledge—written from an expert’s view, crammed with every feature, and organized by internal logic rather than user needs.
Whenever possible, reframe them for the intended user: explain the intent, group by use case, and keep it simple.

Communicate Effectively 

  • Tame your inbox – Set up filters to keep critical messages visible amid the noise.
  • Be intentional with meetings – Know why you’re invited before accepting. Saying "No" is a skill. Long meetings with many people are costly; make them count.
  • Keep retrospectives actionable – The value is in the follow-up. Track action items and ensure they happen.
  • Adapt to the team’s style – Use their tools and tone, even if it’s different from what you’re used to.

    • Make Early, Smart Suggestions

    It’s natural to wait before making suggestions, but don’t wait too long—momentum matters. The first 90 days set the tone for your role.

    Look for:

    • Obvious gaps – Missing processes, outdated tools, unassigned work.

    • Avoided problems – Pain points that no one wants to own.

    • Low-bar opportunities – When a solution is bad or nonexistent, you don’t need deep expertise to make an impact.

    Some of my biggest wins came from tackling tasks outside my skill set—because no one else wanted to touch them. If you approach them with curiosity, persistence, and a willingness to learn, you can quickly add value.

    Even small fixes to frustrating workflows can dramatically improve team morale and productivity.


    Final Thought

    Your first weeks aren’t just about learning the ropes—they’re a unique chance to see with fresh eyes. Notice what’s confusing, inefficient, or broken before you become used to it.

    By combining curiosity with action, you can contribute meaningfully while still finding your feet.


    Related Posts



    More Information

    Books

    by Atul Gawande

    Shows how simple checklists can dramatically improve consistency, onboarding, and problem-solving.

    Video Reviews  1 &  2



    The Culture Map: Breaking Through the Invisible Boundaries of Global Business by Erin Meyer

    Excellent for decoding communication and decision-making styles, especially if you work in international or cross-functional teams.
     



    Crucial Conversations: Tools for Talking When Stakes are High  by Kerry Patterson, Stephen R. Covey,  Joseph Grenny,  Ron McMillan,  Al Switzler

    Practical techniques for staying calm, respectful, and effective during emotionally charged feedback moments.





    Posted by at No comments:
    Labels: ,

    Tuesday, January 24

    Never Ask for Feedback You are Not Willing to Listen to

    W

    hen you ask for feedback, you’re not just gathering opinions—you’re making a implicit promise to listen and think about the feedback . The person giving it needs to feel heard. That doesn’t mean you have to do exactly what they say, but you do have to respond with honesty, humility, and genuine respect. If you can’t act on it, explain why—openly and without defensiveness.

    Some people dismiss this as “touchy-feely.” Don’t. If you get it wrong, the fallout can be ugly.

    The Day Feedback Went Spectacularly Wrong

    At a previous company, I sat in an open-plan office where my team shared space with another group I’ll call Team Marmalade, the where working on Project Indigo. They were a constant source of vicarious learning—and sometimes cautionary tales.

    Most managers, when they need to discuss sensitive topics, book a private meeting room. It’s quieter, more focused, and free from an audience. For reasons only he knew, Team Marmalade’s manager decided to skip the boardroom and hold an important meeting right in the middle of the cubicles. I heard everything. So did the entire office. And by the end, I suspect he wished no one had.I suspect he wished no one had.

    Most managers when talking to their team about important and Most managers, when discussing important or sensitive topics with their teams, book a boardroom. These rooms are quiet, private, and free of interruptions. For reasons only he knew, Team Marmalade’s manager decided to hold an important meeting right in the middle of the cubicles. I heard everything. The entire office heard everything. And unfortunately, so did his team. Normally, it’s a good thing when a team hears their manager. But by the end of this particular meeting, the manager likely wished everyone would just forget it had ever happened.

    The meeting began reasonably enough. The manager explained that the team’s process wasn’t working, results were slipping, and change was needed. He then invited the team to share ideas.

    They did—enthusiastically. They identified problems, proposed fixes, and mapped out ways to boost productivity. The suggestions were clear, practical, and—if implemented—would have solved much of what he’d raised.

    But with each idea, the manager’s expression grew more and more alarmed. Eventually, he cut them off:

    “I can’t tell upper management any of this. We’ll just have to stick with what we were doing.”

     

    The Downward Spiral

    Morale dropped like a stone. Productivity followed.

    A few weeks later, the team leader (not the manager) managed to lift spirits through… let’s say creative morale-boosting tactics. They might have worked if results had soared. They didn’t. The team’s output improved slightly but never reached even the low levels from before the “feedback incident.”

    Worse, the team’s attitude shifted. On the surface, they seemed fine. Underneath, they were frustrated, angry, and disengaged. Nothing had really been forgiven—or forgotten.

    Then one day, while the manager was offsite and the team leader’s “creative” tactics were in full swing, upper management walked in. The scolding was loud, public, and humiliating.

    And still—had all the managers forgotten meeting rooms existed?

    Morale collapsed again. So did productivity. This time, recovery took months. 

    And this time, it took a long time for Team Marmalade to recover.

    This isn’t the only time I’ve seen a request for feedback go wrong—but it was definitely the worst.

    If you don’t treat feedback with respect, those giving it can become cynical, resentful, and disengaged. By the time you’re ready to take action, your team or community may no longer care to listen.


    The Lesson

    I’ve seen feedback requests go wrong before, but this one was catastrophic.

    If you ask for input but then ignore, dismiss, or shut it down, you teach people that speaking up is pointless. Cynicism sets in. Engagement erodes. And when you are finally ready to make changes, it may be too late—because the people you need have stopped caring.


    Related Posts



    Posted by at No comments:
    Labels: ,

    Monday, January 23

    Lessons from Project Indigo: A Slow-Motion Train Wreck

    M

    y boss called me into his office and asked if I thought Project Indigo could be completed on time.

    Strange question. My opinion on Indigo’s feasibility was no secret — I’d told him more than once. Indigo was due to start the next business day. Was he having last-minute doubts? Or wondering if I’d make trouble with his superiors or the new hires?

    It felt like being dropped into an Asch conformity experiment. I had estimated Indigo would take five years with a team of seven. The other senior developer and the project manager? Nine months with a team of five.

    Even my five-year figure was generous, thanks to the anchoring effect. Every shred of my experience told me it was a multi-year slog, yet surrounded by confident people quoting nine months, I began to doubt myself.



    Mistake #1 – The Compromise Trap

    Under my boss’s gaze, I suggested a “compromise”: the PM’s detailed schedule said the first module would be done in a month. If we measured progress after that month, we’d know how long the whole thing would take.

    That was my first mistake. The problem wasn’t a lack of evidence — Indigo was a reboot of a project that had already failed once. We knew exactly how long it would take.

    If my boss was looking for a reason to kill the project, I’d just blown my best chance. Or maybe he only wanted to know if I’d be a “team player.” In a company as internally competitive as ours, that wasn’t paranoia — just experience talking.


    Mistake #2 – Not Locking in a Review

    I also failed to set a firm, calendar-booked review meeting with clear evaluation criteria. If it’s not scheduled then and there, it won’t happen.

    Later, I learned to make post-spike reviews non-negotiable. They led to pivots in some projects and smaller, life-saving adjustments in others.

    Still, my partial resistance paid off: the PM and other senior dev ran Indigo, while I stayed on Project Teal — the project Indigo was supposed to replace. Perfect spot: close enough to watch the train wreck, far enough to avoid the flames. 


    Month One – Nothing Done

    After a month, I checked the tracker: zero completed stories. The PM insisted they were on track because they’d “partially completed many stories.”

    I pointed out that partially completed work is impossible to measure reliably. He said his “years of experience” told him they’d make the deadline.

    I told my boss it wasn’t going well. He said it was “early days” and he trusted the PM. 


    Year One – Still Nothing Through QA

    A year in, not a single story had passed QA. Some tasks had passed QA, but tasks aren’t supposed to be tested alone — they’re part of stories. 

    Indigo’s stories were massive. In fact, stories were functioning like epics, and tasks were functioning like stories. The estimates? Pre-determined before anyone started.

    Using completed tasks (gappy though they were), I built a chart showing Indigo would take eight years. My boss dismissed it: “We’ve learned a lot, we’ll do better this year.” When I asked how long he thought it would take, he didn’t answer.

    By this point, canceling the project would have been too embarrassing. I don’t think anyone expected to meet the deadline. They wanted the project approved and assumed “few months” of overrun would be fine. It turned into years.


    Year Two – Scope Games

    Real scope dropped (low-priority features cut), but on paper scope increased as hidden work surfaced. New stories were added.

    Management panicked: No more new stories. No more splitting stories.
    This, of course, made stories even bigger and harder to push through QA.


    Year Three – Reality Check (Sort of)

    Management reversed course: Split stories, re-estimate to real values. The backlog improved, but stories were still too big. QA remained a bottleneck, and the backlog kept growing.

    The PM was now flying in from interstate every two weeks, reputation on the line, venting to anyone who’d listen. The original team, except him, was gone.


    The Endgame

    I left for greener pastures.

    Years later, over coffee, the final Indigo team lead told me the ending:

    • Year 5: A prototype was shown to beta customers. They hated it.

    • Year 6: Project Indigo was canceled. The dev team was laid off.

    My former boss had been right — there was a lot to learn from Indigo. Unfortunately, the lessons didn’t stop after Year One.


    Final Thoughts

    Most of Indigo's problems I have seen to a lesser extent in other projects. However the words "lesser extent" are doing a whole lot of work in the previous sentence. 

    There was one difference that was a difference of kind rather than a difference of scale, one mistake that doomed Indigo from the very start. A mistake that caused many of the other problems.


    Mistake #0 – Letting Politics Determine Estimates

    There were other projects were I was pressured to reduce my estimates, as if re-estimating would change the real completion time. There was only one project that I have ever been on where I was given the estimate I was supposed to come up with before hand.   


    Related Posts

    More Information

    Article

    Videos




    Posted by at No comments:
    Labels: , ,

    Saturday, January 21

    Learning Plans for 2023

    C

    urrent Focus Topics

    Focus People Tasks
    Abstract Communication,
    Coaching &            
    Leadership
    		 Category Theory,
    Abstract Algebra & 
    Lambda Calculus
    Concrete Reducing Stress &
    Refocusing
    the Mind
    		 Swift



    Changes for 2023

    I am currently spreading myself to thin between to many study topics. For the upcoming year I intend to slowly finish up many of the topics and narrow my focus.



    Category Theory

    I feel that am pretty much done with Category Theory, Abstract Algebra  &  Lambda Calculus. I will experiment  more with practical applications of the theory, and some of the functional swift libraries then close the topic off in March with some final revision. I have been building up an Anki flash card deck which I will share. I won't replace this topic with another. I will leave that quadrant blank for now.



    Leadership

    I worked my way though a large chunk the courses and books I had earmarked for these topics and I am also applying that knowledge. I am going to finish Communication & Leadership in June and Coaching in October.  I intend to study creative writing in 2024. 



    Wellbeing 

    I am going continue on with this. The only changes I am making from last year is to alternate my exercise routines and restart my music practise.


    Swift

    There is still a lot I want to do in this area, so this one will be keeping me busy.


    Related Posts

    Related Artefacts

    Posted by at No comments:
    Labels:
    Subscribe to: Comments (Atom)