Understanding the "Seven Year Shift" for Career Growth

Man, Richard Hamming's talk is doing a number on me. So much of what he said, back in 1986 is still relevant today! Calling out Hamming's "Seven Year Shift" policy that resonated so much with me...this talk should go down as one of the best career talks in history...

Hamming's suggestion of a "significant, if not complete, shift in your field" every seven years might seem counterintuitive at first. Why change when you've built expertise and a reputation in a particular area? Here's a closer look at his reasoning, drawing on his insights from the sources you provided:

1. Combating Stagnation and Maintaining Originality:

Hamming argues that staying in one area for too long can lead to stagnation. You become overly reliant on familiar methods, your thinking becomes less flexible, and you may miss out on new and emerging opportunities.

• He observes: "What happens to the old fellows is that they get a technique going; they keep on using it. They were marching in that direction which was right then, but the world changes. There's the new direction; but the old fellows are still marching in their former direction."

This idea emphasizes the importance of actively seeking new challenges and perspectives to keep your thinking fresh and continue growing.

2. The Power of "Beginner's Mind"

By shifting to a new area, you force yourself back into a "beginner's mind" state. You're no longer the expert, which can be liberating. This allows you to approach challenges with fresh eyes, ask fundamental questions, and potentially make connections that you wouldn't have seen otherwise.

• Hamming, reflecting on his own career choices, says: "...when error correcting codes were well launched, having these theories, I said, 'Hamming, you are going to quit reading papers in the field; you are going to ignore it completely; you are going to try and do something else other than coast on that.' I deliberately refused to go on in that field. I wouldn't even read papers to try to force myself to have a chance to do something else."

He actively chose to become a "beginner" again, opening himself up to new possibilities.

3. Planting New "Acorns" for Future Growth

Hamming uses the metaphor of planting acorns that grow into mighty oaks to illustrate the importance of consistently nurturing new ideas and areas of expertise.

• He advises: "You have to change. You get tired after a while; you use up your originality in one field. You need to get something nearby... so that you don't go stale... You can do something about this, but it takes effort and energy. It takes courage to say, 'Yes, I will give up my great reputation.'"

This suggests that even giving up a degree of established expertise can be beneficial in the long run, as it creates space for new growth and potentially even greater accomplishments.

4. The "Seven Year Shift" in Today's Context

While the specific timeframe of seven years might not be a rigid rule, the underlying principle of embracing change and seeking new challenges is highly relevant for professionals today:

• Rapid Technological Advancements: In fields like technology, where change is constant and skills can become obsolete quickly, actively seeking new challenges and updating your knowledge base is essential.
• The Evolving Nature of Work: The rise of the gig economy, remote work, and the increasing demand for adaptable skillsets mean that professionals need to be prepared to navigate career transitions more frequently.
• Personal Growth and Fulfillment: Beyond external success, seeking new challenges can contribute to personal growth, prevent boredom, and keep you engaged and motivated throughout your career.

Hamming's "seven year shift" isn't about abandoning your expertise or making drastic career changes for the sake of it. It's about recognizing the dangers of complacency, embracing a mindset of continuous learning, and actively seeking out new challenges that can keep you engaged, adaptable, and at the forefront of your field.

Timeless Advice for Ambitious Software Engineers

Timeless Advice for Ambitious Software Engineers

Back in 1986, Richard Hamming, a highly respected figure in the world of mathematics and computer science, gave a talk at Bell Labs titled "You and Your Research". Although he was speaking to researchers, his advice is incredibly relevant for anyone, especially those of us in software engineering, who want to make a real impact. 

One of the most important things Hamming talks about is the need to work on problems that matter. Don't just settle for the routine stuff. It's not just about luck; it's about preparing your mind to spot and seize opportunities. What are the biggest headaches in your area of software engineering? What problems, if solved, would make the biggest difference? Focusing on impactful problems increases your chances of doing truly great work.

Hamming was a big believer in having a growth mindset. To him, obstacles weren't roadblocks, but chances to think differently and come up with something innovative. Software engineers constantly face limitations – whether it's resources, technical issues, or those pesky bugs. See these as opportunities. Did you discover a clever workaround for a bug? Document it, share it with your team, and turn that challenge into an advantage.

There's no shortcut to great work – it demands deep commitment. Hamming believed that when you fully immerse yourself in a problem, your subconscious mind keeps working on it, often leading to breakthroughs. As software engineers, this means dedicating ourselves to exploring solutions thoroughly. Don't be afraid to go deep – research, experiment, refine your code. The effort will shine through in the quality of your work.

Even the most brilliant work can go unnoticed if you don't communicate it effectively. Hamming believed in "selling" your work, no matter how good it is. For us, this means becoming excellent communicators – both in writing and presentations. A well-written design document or a compelling presentation is crucial for getting buy-in from stakeholders.

The world of software engineering is always changing, so never stop learning. Hamming believed in switching things up in your field to avoid getting stale. Stay current with the latest technologies, languages, and methodologies. Make time to read industry publications, attend conferences, and connect with the wider software development community.

What are you first-class at? Hamming stresses the importance of introspection and self-awareness. He encourages individuals to be honest about their capabilities, acknowledging both strengths and weaknesses. To discover what you're "first-class" at, you must examine your career, passions, and natural abilities. What are you naturally drawn to? What tasks or projects have you excelled at in the past? Don't be afraid to specialise. While a broad skillset is valuable, becoming a true expert in a niche area allows you to make unique contributions. Identify that area within software engineering where you can truly shine and relentlessly develop your expertise. This focused approach increases your chances of producing exceptional work and leads to a more fulfilling career.

Hamming's talk is a treasure trove of wisdom. By focusing on the right problems, embracing challenges, being truly committed, communicating effectively, and constantly learning, you give yourself the best shot at creating impactful and lasting work as a software engineer.

Click here to download the full PDF

Click here to download the podcast generated by Google's Notebook LM.

Having some more fun with chatGPT o1-preview

So it's been about 5 hours that I've been playing around with chatGPT o1-preview today. I had to wait a week to get my credits going again. Last Sunday, I made a simple resource planner forecasting tool for software engineering managers. Today I decided to explore something I've been putting off for a very long time, for more than a decade actually. I believe there is a gap is software planning tools, starting with the mental model of defining the software system architecture, breaking it down into services, APIs and dependencies, forming the teams around the architecture, and then integrating work package planning with the architecture definition.

My goal is to make planning work packages easier, dating back to when I described in detail how I managed a very large scale software delivery here. I want to bring this thinking into a tool. When planning projects or any new initiatives, when defining the work package, one can pull all the details needed from a primary source, driven by the software architecture and dependencies, we can solve the risk of missing critical tasks, ensuring all related teams are included in the overall planning.

So today, after going through a few rounds of building these workflows, with chatGPT as my copilot - I decided to scrap everything, and begin with the end in mind. So the first iteration is a working backwards from the end visualizations, setting up the mental model to mature further. The tool is available in a separate page here, and embedded in this blog post. There are two example software systems: 1\ A generic video streaming app called "StreamView"; 2\ A generic contact center system called "ConnectPro". I have a long history with building video streaming apps, and for the last 3 years I've been building a contact center for AWS Support.

At first I started creating the workflows from scratch like capturing the system details through some forms and workflows. The interaction was amusing, classic scope creep, change of requirements, build-run-change-iterate cycles. Do this long enough, chatGPT loses context after a while and messes things up. Then I directed chatGPT to synthesize its own system architectures, using its own knowledge of software architecture and whatever it learnt about video streaming apps and contact center stacks. I instructed it to generated its own services, dependency trees and basically generate the fake data to drive the mental model. Now we (chatGPT and I) have a good base to start refining the mental model, baseline a data model, and then build the advanced software planning tool from there. Ideally, the end goal is a component or service that can be plugged into the various software planning tools in the market today. I feel the lack of an integrated software system dictionary is one of the reasons why we still experience poor software project management today. Let's see how far I get on with this vision!

The more I interact with chatGPT, the more I'm blown away. The key learning takes me back to my days when I used to write technical requirements, system use cases. All of this knowledge is now needed to prompt these LLM GPTs. It is amazing how chatGPT o1-preview synthesizes the requests, applies chain-of-thought reasoning, and usually gets an MVP right on first attempt. The interaction will take several hours, or even days - but I can only see this thing getting so much better!

System Visualization

Team Relationships Visualization

Team Breakdown

Team Identity	Team Name	SDM	PMT	Size of Team	Engineer Names	Services Owned

How I used ChatGPT o1-preview to build a rough interactive software engineering resource forecasting model

Seed Prompt for tool (click here to play with it): I am a software engineering manager. A large part of my job is understanding the engineering resource utilization for my engineering team. I manage multiple engineering teams of varying sizes from 5 people to 20 people in a team. When estimating software projects, understanding availability of productive engineers is important for planning purposes. Help me build an interactive resource forecasting tool, that can be fully self-contained within browser app, embedded in a google blogspot page. The tool must include inputs for: 1\ Funded team size; 2\ Current Available engineers (i.e. actual current size of team). The tool must account for the time it takes for hiring new engineers, ramp-up time, learning, etc. before they can be deemed as productive for committing to project work. The tool must show a table the resource plan over 52 weeks in the year, and include a visual graph to show how the team size grows to meet funded size. Research the best methods in software engineering management, and create the tool that can help software managers have a good model for resource utilization. The tool can store information in the local user browser storage as needed. Remember, I need the full code to be fully self-contained so I can run the tool from within a google blogspot page.

Prompt for this article: Great I think we have good baseline version to start with. Now using your PhD capabilities, write up an accompanying blog post that details the model, the thinking behind it, and call out the limitations using a critical eye, suggesting improvements for the next version.

Prompt for Image using Dall-E: "An isometric illustration of a diverse engineering team collaborating in a modern office space. They are gathered around a large table filled with charts, graphs, and laptops, discussing and planning. Behind them, a wall-sized calendar and a whiteboard display timelines, Gantt charts, and upward-trending graphs. Include elements like gears and clock icons subtly integrated into the design to symbolize engineering and time management. Use a professional, clean art style with vibrant yet muted colors to convey a serious but engaging atmosphere.

Engineering Resource Forecasting: A Comprehensive Model for Team Planning

By ChatGPT o1-Preview (took about 4 hours to get the tool to version 1)

Effective resource planning is crucial for engineering teams aiming to meet project deadlines, optimize productivity, and manage budgets efficiently. The Engineering Resource Forecasting Tool is designed to help managers and team leads forecast their engineering resources over a year, considering various real-world factors such as hiring rates, attrition, ramp-up times, efficiency, leave days, and public holidays.

In this blog post, we'll delve into the model behind the tool, explore the thinking that shaped its development, critically analyze its limitations, and suggest improvements for future iterations.

---

Understanding the Model

1. Objectives of the Tool

The primary goals of the Engineering Resource Forecasting Tool are to:

• Forecast Team Size: Predict how the engineering team will grow or shrink over time.
• Calculate Effective Capacity: Determine the actual productive capacity of the team, considering factors that reduce availability.
• Assist in Planning: Provide insights for hiring strategies, resource allocation, and project scheduling.

2. Key Components of the Model

The model incorporates several essential elements:

• Funded Team Size: The maximum number of engineers that the budget allows.
• Current Available Engineers: The starting point for the forecasting, representing the existing team.
• Hiring Rate and Time: The rate at which new engineers are hired and the average time it takes for them to join.
• Ramp-Up Time: The period new hires require to reach full productivity.
• Attrition Rate: The expected percentage of engineers who will leave the team annually.
• Efficiency Factor: The proportion of time engineers spend on productive work.
• Leave Days and Public Holidays: Time when engineers are not available due to vacations and holidays.

3. Model Calculations

a. Effective Engineers

The number of effective engineers is calculated weekly by adjusting the total number of fully ramped-up engineers for efficiency and availability:

Effective Engineers = Total Ramped-Up Engineers × Efficiency Factor × (Weekly Available Days / 5)

b. Weekly Available Days

Engineers aren't available all five working days each week due to leave and public holidays:

Weekly Available Days = 5 - ((Annual Leave Days + Public Holidays) / 52)

c. Attrition Modeling

Attrition reduces the team size over time:

• Weekly Attrition Rate:

Weekly Attrition Rate = Annual Attrition Rate / 52

• Cumulative Attrition: The total number of engineers who have left the team up to a given week.

d. Hiring and Ramp-Up Process

• Hiring Pipeline: Represents engineers who have accepted offers but haven't started yet.
• Ramping Engineers: New hires who are in the process of ramping up to full productivity.

e. SDE-Weeks and SDE-Days

• SDE-Weeks: Sum of effective engineer contributions per week within a month.
• SDE-Days: Sum of effective engineer contributions per day within a month.

These metrics provide a more granular view of the team's productive capacity.

---

Thinking Behind the Model

1. Realistic Representation

The model aims to mirror real-world scenarios by considering:

• Time Delays: Hiring and ramp-up times introduce delays between initiating a hire and gaining full productivity.
• Non-Productive Time: Leave, holidays, and non-productive activities reduce actual working time.
• Attrition Effects: Engineers may leave the team, impacting capacity and necessitating replacement hires.

2. Balancing Simplicity and Complexity

While the model incorporates multiple factors, it maintains usability by:

• Using Average Rates: Distributes leave, holidays, and attrition evenly over the year for simplicity.
• Assuming Linear Processes: Hiring and ramp-up are modeled as linear processes without accounting for fluctuations.

3. Providing Actionable Insights

By visualizing the forecast through charts and tables, the tool helps managers:

• Identify Hiring Needs: Determine the hiring rate required to meet team size goals.
• Plan for Attrition: Anticipate capacity reductions due to attrition.
• Adjust Strategies: Modify inputs to explore different scenarios and their outcomes.

---

Limitations and Critical Analysis

Despite its usefulness, the model has several limitations:

1. Uniform Distribution Assumptions

• Leave and Holidays: The model assumes that leave days and public holidays are evenly distributed throughout the year. In reality, leave may cluster around certain periods (e.g., summer vacations, year-end holidays), leading to temporary drops in capacity.
• Attrition Timing: Attrition is modeled as a steady rate, but actual departures may occur unpredictably and in clusters.

2. Lack of Granular Ramp-Up Modeling

• Binary Productivity: The model assumes engineers are either ramping up or fully productive after the ramp-up period. It doesn't account for gradual increases in productivity during ramp-up.
• Individual Variations: All new hires are treated identically in terms of ramp-up time and efficiency, ignoring individual differences.

3. Hiring Constraints and Real-World Challenges

• Hiring Rate Feasibility: The model calculates the hiring rate needed to meet targets but doesn't consider the practical challenges of achieving that rate, such as market conditions or recruitment resource limitations.
• Candidate Pipeline Variability: It doesn't account for fluctuations in candidate availability or acceptance rates.

4. Simplified Efficiency Factor

• Static Efficiency: The efficiency factor is constant over time, not accounting for potential improvements or declines due to training, process changes, or team dynamics.
• Team Composition: It doesn't differentiate between engineers with different skill levels or specializations.

5. Absence of Project Dependencies

• No Task Modeling: The model focuses on resource capacity without linking it to specific project tasks or timelines.
• Overtime and Workload Peaks: It doesn't account for periods when engineers might work overtime or when workload exceeds capacity.

6. Economic and External Factors

• Budget Changes: The funded team size is assumed constant, ignoring potential budget cuts or increases.
• External Events: Unforeseen events like economic downturns, pandemics, or natural disasters are not modeled.

---

Suggestions for Improvement

To enhance the model's accuracy and applicability, future versions could consider:

1. Incorporating Seasonal Variations

• Variable Leave and Holiday Distribution: Model leave and public holidays based on historical patterns to reflect periods of low and high availability.
• Attrition Peaks: Adjust attrition rates to account for known periods of higher turnover.

2. Enhanced Ramp-Up Modeling

• Gradual Productivity Increase: Implement a ramp-up curve where productivity increases incrementally over the ramp-up period.
• Individualized Ramp-Up: Allow different ramp-up times for different roles or experience levels.

3. Realistic Hiring Constraints

• Recruitment Capacity Limits: Introduce maximum hiring rates based on recruitment team capacity.
• Candidate Pipeline Dynamics: Factor in time-to-fill variations, candidate drop-off rates, and competition in the job market.

4. Dynamic Efficiency Factor

• Efficiency Over Time: Allow the efficiency factor to change over time, reflecting process improvements or team fatigue.
• Role-Based Efficiency: Differentiate efficiency factors for various roles or seniority levels.

5. Integration with Project Planning

• Task-Level Planning: Link resource capacity to project tasks and milestones to assess whether capacity meets project demands.
• Risk Modeling: Incorporate risks and uncertainties that could impact timelines and capacity.

6. Economic Scenario Planning

• Budget Flexibility: Allow for adjustments in the funded team size based on potential budget changes.
• External Shocks: Introduce scenarios for external events that could affect hiring, attrition, or productivity.

7. User Input Flexibility

• Custom Time Frames: Enable users to adjust the time frame of the forecast beyond a single year.
• Data Import: Allow users to import historical data to better tailor the model to their organization's patterns.

---

Conclusion

The Engineering Resource Forecasting Tool provides a solid foundation for planning and visualizing engineering team capacity over time. By accounting for critical factors like hiring, ramp-up, attrition, efficiency, leave, and holidays, it offers valuable insights for managers.

However, like any model, it simplifies complex real-world dynamics to remain practical and user-friendly. Recognizing its limitations is essential for interpreting the results accurately and making informed decisions. By incorporating suggested improvements, future versions can offer even more robust and precise forecasting, aiding organizations in navigating the challenges of resource planning.

---

About the Author

[Your Name] holds a PhD in [Your Field] and has extensive experience in project management, resource planning, and organizational development. Passionate about leveraging data-driven models to solve practical problems, [Your Name] contributes to advancing tools and methodologies that enhance operational efficiency.

---

Note: The Engineering Resource Forecasting Tool is intended as a planning aid and should be used in conjunction with professional judgment and other planning tools. Always consider your organization's specific circumstances when making staffing decisions.

The Jenga of life

Jenga metaphor #thismightnotwork

It's been ages since I last shared a metaphor on this blog. This one hit me during my morning walk today, 8th August 2024. As I was trudging through the early morning mist, my brain made an odd connection: life is kinda like a game of Jenga.

You know Jenga, right? That game where you're trying to build the tallest tower possible by yanking out blocks and stacking them on top. It's all fun and games until someone knocks the whole thing over. But today, I saw it differently.

The Baseline: Your Value System

Picture this: you start with a perfect Jenga tower. All the blocks neatly stacked, everything solid and stable. That's you. That's your life, your values, everything you stand for. It's rock solid, built on all the principles you've picked up over the years.

The Dangerous Dance of Compromise

Now, here's where it gets interesting. Every time you play Jenga, you're taking a risk, right? You pull out a block, the tower gets taller, but it's wobbling more. In life, it's kinda the same deal:

• Maybe you tell a little white lie. No big deal, right? But they start to add up...
• Or you cut corners on a business deal. Just this once, you tell yourself.
• Perhaps you're racking up some debt. One credit card becomes two, becomes three...
• Or you let slide something that goes against your values. It's just a small thing, a papercut. But man, those papercuts sting after a while.

Every time you look the other way, every time you compromise, you're pulling out another block. Your tower might be getting taller, but it's getting shakier too.

The Inevitable Collapse

We all know how Jenga ends - with a crash and blocks all over the floor. Real life isn't always that dramatic, but the consequences can be way worse. All those little compromises? They add up:

• Those white lies might snowball into you being known as "that guy who can't be trusted".
• That shady business deal? It might come back to bite you in the butt, big time.
• And that debt? Before you know it, you're drowning in it.
• As for those "minor" infractions? They chip away at your self-respect, bit by bit.

The Lesson: Handle with Care

So what's the point of all this Jenga talk? It's pretty simple: be careful with your values, folks. Every choice you make, everything you do, it's like moving a block in your personal Jenga tower. Some moves might seem like no big deal at the time, but they all add up to how stable (or unstable) your life is.

This doesn't mean you should never take risks or change your mind about stuff. Heck, growing as a person often means shaking things up a bit. But it does mean being careful about the choices we make and thinking about where they might lead us down the road.

Building a Stable Tower

So, how do we use this Jenga metaphor to build a life that doesn't topple over at the slightest breeze?

1. Know your foundation: Take some time to think about what really matters to you. What are the blocks at the bottom of your tower?
2. Think before you pull: Before you do something that goes against your values, ask yourself if it's really worth it. Is that short-term gain worth making your whole tower wobble?
3. Shore up your base: Work on making your core values stronger. Read books, hang out with people who inspire you, practice what you preach in the little day-to-day stuff.
4. It's okay to rebuild: If you realize you've compromised too much, don't be afraid to start over. Sometimes you gotta go back to basics to build something that'll last.
5. Play the long game: Remember, life isn't a race to build the tallest tower as fast as you can. It's about building something that'll stand up to whatever life throws at it.

As we're all fumbling our way through this game called life, let's keep this Jenga thing in mind. Every decision, every compromise, every value we ignore - they're all blocks in our tower. Handle 'em carefully, think about your moves, and try to build a life that stands tall not just in height, but in being rock-solid and true to who you are.

So, what blocks are you moving around in your life's Jenga tower? And the million-dollar question: how stable is your foundation? Something to chew on, isn't it?