We Already Run Unpredictable Systems. They’re Called Humans

Most “AI risk” conversations in large organisations start in the wrong place.

They start with: “Can we trust AI?”

That question sounds sensible, but it hides a contradiction that every leader lives with daily: we already trust an army of uncontrolled entities – humans – to make changes to production systems. We are inconsistent. We misunderstand requirements. We have good days and bad days. We leave. We improvise. We ship bugs.

And yet the world keeps turning.

So the real question is not whether AI is trustworthy in some abstract sense. The real question is this:

What makes humans acceptable risk in software delivery, and can we wrap AI in the same kind of controls?

Once you look at it that way, the path forward becomes less philosophical and more operational.

Organisations don’t trust people, they trust the system

In any organisation that ships reliably, we don’t “trust” engineers to always be correct. We assume the opposite: people will make mistakes, especially under time pressure, ambiguity, and complexity.

What we actually trust are the mechanisms that bound human error:

Peer review and change approval
Automated tests and quality gates
Static analysis, scanning, and policy checks
Staged rollouts, canaries, and monitoring
Incident response and postmortems
Access controls and segregation of duties
Audit trails and accountability

In other words, we trust the factory.

This matters because it reframes AI adoption from a moral debate into a delivery design problem. If your factory is weak, AI will amplify chaos. If your factory is strong, AI becomes another worker that can be constrained, audited, and measured.

Why AI feels scarier than humans

If humans are less predictable, why do risk-averse organisations tolerate them more than AI?

Because humans are easier to understand, challenge, and hold accountable in ways AI often isn’t.

Humans share context you never fully wrote down:

Why this requirement matters
What “good enough” means for this team
What will upset customers, regulators, or internal stakeholders
When to stop polishing and ship
When something “feels wrong” even if it passes the formal spec

Humans also carry organisational accountability. When a change causes harm, you can ask: who approved this, what was the rationale, what changed, what did we learn?

AI flips those properties:

It can look confident while being wrong.
It can be correct for reasons you can’t explain.
It doesn’t naturally know your priorities unless you encode them.
Accountability gets fuzzy fast (who is responsible: the dev, the tool owner, the vendor?)

That’s not a reason to avoid AI. It’s a reason to adopt it through controls that restore clarity and accountability.

The control problem is not new. Agile exists because we rarely know what we want

There’s a deeper issue that sits underneath the fear: steering.

Organisations often assume that software development is “translate requirements into code.” In reality, it’s discovery. Requirements are incomplete. Constraints emerge late. Tradeoffs become visible only once you build something. This is why Agile methods exist: to make learning cheap and constant.

Humans are good at discovery because they push back, ask questions, and clarify intent.

AI, by default, does something else. It generates plausible progress. It will fill in gaps. It will guess. It will happily move forward even when the problem statement is mushy.

So the practical risk is not “AI writes bad code.” The practical risk is:

AI accelerates you toward a misunderstood problem.

The fix is not to demand perfect AI. The fix is to treat intent as a first-class engineering artefact.

The pivot: stop trusting the actor, start verifying the outcome

If you want a serious, non-hyped approach to AI in software delivery, it’s this:

Shift from trusting who did the work to verifying what the work achieves and how.

This is where software has an advantage over many domains. In software, we can build verification into the pipeline. We can turn intent into executable checks.

Not perfectly. Not for everything. But far more than most organisations currently do.

Pragmatically, this means investing in three things:

1. Make intent testable

When requirements are ambiguous, don’t ask AI to “understand better.” Encode intent:

Examples and acceptance criteria that can become tests
Contract tests between services
Golden path scenarios that reflect what matters
Non-functional intent: performance budgets, reliability expectations, security constraints

This is not “more process.” It’s creating steering inputs that scale, whether the worker is a human or an agent.

2. Protect the confidence mechanisms

There is a real failure mode with agentic AI tooling: an agent can make tests pass by weakening the tests.

If you do nothing, you can end up with a pipeline that produces false confidence. That’s worse than not adopting AI at all.

The practical controls are:

Define “protected” test suites (golden paths, contract tests, release confidence checks).
Require stricter approvals for changes to those suites.
Add a two-key rule: any PR that changes tests requires a second reviewer who is not the requester.
Where needed, add external smoke checks or synthetic monitoring that the agent cannot modify.

You don’t need perfection. You need a small set of checks that stay honest.

3. Put autonomy where verification is strong

Where the work is mechanical and verification is strong, autonomy is safe.
Where intent is fuzzy and verification is weak, autonomy is dangerous.

This isn’t ideology. It’s a deployment strategy.

What this looks like in practice: “permission lanes” for AI

Large enterprises get stuck when AI is treated as a single decision: “Are we doing AI or not?”

A better model is permission tiers – how much autonomy do we grant, where, and under what controls.

A pragmatic set of lanes looks like this:

Lane 0 (Assistive): AI suggests, summarises, drafts. Humans do and decide.
Lane 1 (PR Agents): AI can create branches and open PRs. Humans approve. AI never merges.
Lane 2 (Pipeline Assist): AI can triage CI failures, assemble release notes, recommend. It cannot bypass gates or deploy.
Lane 3 (Ops Assist): AI can gather signals, draft runbooks, propose mitigations. No production write actions without explicit human confirmation.

Most risk-averse organisations can stop at Lane 1 for a long time and still get real value, because Lane 1 is where toil lives and blast radius stays small.

Start with the least controversial win: dependency and security upgrade PRs

If you want a first “agentic” use case that makes sense to engineering leaders, it’s this:

A PR-level agent that creates dependency and security upgrade pull requests, with evidence attached.

It is least controversial because it automates effort, not decision-making.

Why it works:

It’s repetitive, high volume work that teams delay.
It directly reduces known security exposure.
It produces measurable outcomes (time-to-remediate, backlog health).
It fits neatly inside existing controls: PRs, reviews, gates, audit logs.

The rule is simple: the agent can work overnight, but it cannot ship anything. It can only propose changes that pass the same gates humans must pass.

The real AI enabler is not the agent, it’s the factory

You can’t bolt AI onto a chaotic SDLC and expect good outcomes.

AI surfaces weaknesses that were already there:

inconsistent quality gates
weak tests
unclear ownership
fragmented CI/CD tooling
missing standards and docs

If you want safe AI adoption, your early investment is not “pick the best model.” It’s:

define a minimal baseline for quality
standardise the feedback loop
codify engineering intent into artifacts the pipeline can enforce

Then AI becomes a multiplier for an already controlled system, not a wildcard thrown into production.

If you were hoping for a magic tool or model, there isn’t one. Fix the factory first, then AI becomes a multiplier.

Solving the ‘Hero’ Paradox: Strategies for a Resilient Software Development Culture

In the intricate world of software development, one phenomenon occasionally takes centre stage – the emergence of a “Hero.” This individual swoops in amidst crisis, solving problems that no one else can. On the surface, they may seem like a team’s greatest asset, but a deeper dive often reveals hidden complexities. This article explores the phenomenon of the “Hero” in software development, its implications, and strategies to navigate it effectively.

Understanding the ‘Hero’ Phenomenon

The “Hero” in a software development team often arises due to various motivations. For some, the recognition and affirmation of being a problem-solving champion can be irresistible. Others might be driven by a profound sense of responsibility or the fear of the project spiralling into failure. For a select few, the sheer thrill of problem-solving under pressure is motivation enough.

Whatever the cause, it’s essential to realise that this dynamic, while sometimes beneficial in the short term, often holds hidden perils.

The Impact of the ‘Hero’ Issue on Teams

The “Hero” issue can significantly disrupt team dynamics. With one person shouldering most of the workload and responsibility, a dangerous imbalance can form, leading to increased risk and dependency on a single individual. It’s akin to putting all your eggs in one basket.

More subtly, this dynamic can stifle growth and learning for other team members, who may be relegated to bystander roles. Consider the case of DevOps engineers being the sole knowledge bearers of specific activities for the release, configuration, and setup of non-production environments. It can leave the team in a vulnerable state should the DevOps engineer be unavailable.

The ‘Hero’ Issue: Implications for the Organisation

While the impact of the ‘Hero’ issue on teams is substantial, its repercussions extend to the broader organisation. This single-point dependency creates significant risk, primarily in terms of business continuity.

In the event of the “Hero’s” unexpected absence, whether due to illness, attrition, or even a well-deserved vacation, business processes can grind to a halt. Without their unique knowledge and skills, teams might struggle to maintain the pace of operations, leading to delays, cost overruns, and customer dissatisfaction.

Moreover, the ‘Hero’ issue can inadvertently stifle innovation. If one person continuously resolves crises, the organisation may become over-reliant on their methods, stifling the emergence of fresh ideas and novel approaches. Over time, this can lead to stagnation and reduced competitiveness in the fast-paced world of software development.

Recognising and addressing these risks is paramount for an organisation’s long-term success and sustainability.

Addressing the ‘Hero’ Issue

The first step to mitigating the “Hero” issue lies in fostering a culture of shared responsibility. Encourage all team members to contribute their expertise and partake in problem-solving. However, creating this culture extends beyond just day-to-day activities.

A practical performance framework is an essential tool to combat the ‘Hero’ phenomenon. It’s important to define roles, expectations, and responsibilities clearly. This doesn’t just create transparency; it ensures that the performance of each team member is evaluated on a fair and comprehensive basis rather than the frequency of ‘heroic’ acts.

Next, establish robust knowledge transfer mechanisms. This can be through detailed documentation, pair programming, or regular team meetings to share insights and learnings. Project management strategies can also effectively ensure that workloads are evenly distributed and dependencies are minimised.

Lastly, promoting a culture of continual learning and upskilling within the team can help ensure everyone has the confidence and competence to tackle challenges, reducing the need for a “Hero” to swoop in.

Conclusion

Addressing the “Hero” issue is critical for fostering an inclusive, balanced, and cooperative team culture in software development. While it’s easy to laud the efforts of a singular hero, it’s essential to remember the immense power of collective strength, knowledge, and expertise. After all, software development is a team sport, and its true champions are those teams that work seamlessly together, each member contributing their unique strengths towards a shared vision of success.

Turning Downturns into Opportunities: Leading Software Teams Amid Economic Challenges

In the face of economic hardship, business leaders face unique challenges, and financial services companies are no exception. How can we navigate these turbulent waters, particularly within technology and software engineering? The key lies in fostering a work environment that promotes motivation, creativity, and productivity within your teams.

Understanding the Importance

Tough economic times present a unique set of challenges that test the resilience of businesses, but they also offer opportunities for growth and innovation. In such times, your most vital asset is your team. Here are eight compelling reasons why it’s more important than ever to ensure your teams stay motivated, creative, and productive:

Maintaining Competitive Edge: To survive in a struggling economy, businesses must maintain a competitive edge. This can be achieved through innovative ideas, solutions, and strategies that stem from a motivated, creative, and productive team.
Doing More with Less: Productivity is paramount with potential budget cuts and fewer resources. A motivated team will consistently deliver high-quality work, discovering new efficiencies even under challenging conditions.
Reducing Employee Turnover: The cost of losing a talented team member during economic hardship can be significant. By fostering motivation, you maintain the workforce you’ve invested in and create a loyal, committed team.
Adapting to Change: Tough times often require change. Whether it involves pivoting to new markets, shifting product lines, or adopting new technologies, a motivated and creative team can adapt quickly and effectively.
Employee Well-being: A challenging economy can affect mental health. Motivation and creativity can help boost morale, promote positivity, and improve overall well-being, leading to better work performance.
Customer Satisfaction: A motivated team provides better service, improving customer satisfaction and loyalty – critical factors for business continuity and growth during difficult times.
Recovery Preparation: Companies that nurture their teams during challenging times are better prepared for recovery when the economy improves. They will have a resilient, adaptable workforce ready to seize new opportunities.
Team Cohesion: Team unity can be tested during challenging periods. Maintaining motivation and productivity will likely foster stronger bonds, improving collaboration and team dynamics.

Fostering Motivation, Creativity, and Productivity

So, how can we create an environment that fosters motivation, creativity, and productivity within our teams? Here are ten strategies that can help:

Transparent Communication: Keep your team informed about the company’s current situation, strategy changes, and plans. This understanding is the foundation of trust and motivation.
Set Clear Goals: Provide your team with clear, achievable goals that align with the company’s strategic objectives, giving your employees direction and purpose.
Promote a Culture of Innovation: Encourage new ideas and approaches through brainstorming sessions, hackathons, or innovation challenges. Recognise and reward innovative thinking.
Offer Flexibility: Whenever possible, provide flexible working arrangements. Flexibility can enhance productivity and job satisfaction.
Provide Support: Equip your team with the necessary resources to accomplish their tasks. This could involve training, tools, or emotional support.
Encourage Collaboration: Promote a team-oriented environment where everyone’s ideas are valued and heard.
Provide Regular Feedback: Regularly provide constructive feedback. Recognise efforts and accomplishments, and help your team members improve in areas where they struggle.
Invest in Employee Development: Investing in your employee’s growth and development is essential during tough times. Provide training programs, online learning resources, and opportunities to work on different projects.
Promote Well-being: Encourage physical and mental well-being among your employees. Stress levels may be high during hard times, so encouraging breaks, physical activity, and mindfulness practices can boost morale.
Empower Your Team: Give your team members a sense of ownership over their work. Empower them to make decisions and solve problems independently to boost confidence, job satisfaction, and productivity.

In the face of challenging economic times, the true strength of your organisation comes into sharp focus: your teams. Each crisis, while daunting, provides a unique opportunity to redefine norms, innovate, and grow. By nurturing motivation, creativity, and productivity within your teams, you empower them not just to weather the storm but to harness it. In doing so, they become the engine propelling your organisation forward, transforming hurdles into milestones for future growth and success. As leaders, our role is to light the path, inspire, and let our people be the driving force through the storm towards a brighter horizon.

Personal vs. Professional: The Battle Over My Mobile Phone

In the age of constant connectivity, the line between personal and professional life can often blur, a reality I’ve recently grappled with. My personal mobile has become a conduit not only for family chats and friendly catch-ups but also for an unexpected barrage of work-related calls. Sales pitches from eager companies, representatives promoting their services, or recruiters pushing potential candidates have been intrusive in my daily routine.

At first, this felt like an invasion of my personal space. The phone would ring at odd hours, flashing an unknown number or a withheld one, making it an unwelcome surprise. It didn’t take long for me to stop responding to these unsolicited calls. The strategy seemed simple: if a number wasn’t in my phonebook, it didn’t warrant my attention.

However, this approach came with its own set of challenges. In avoiding the unsolicited, I inadvertently missed some vital personal calls. Ironically, the tactic I’d employed to preserve my personal space was disrupting my personal matters.

Recognising the need for change, I decided to adjust my strategy. Now, when an unexpected work-related call comes through on my personal line, I choose to answer but with clear intent. I politely yet firmly explain that the call has reached my mobile, a space I’m striving to keep separate from my professional life. I refrain from sharing work details and kindly request my contact information be removed from their database. The goal is to preserve my personal space, not to rebuff someone earnestly trying to do their job.

I understand that these calls are often made by individuals simply trying to make a living. Each call represents someone’s job and livelihood, which deserves respect. That’s why I believe in being polite but firm. It’s about establishing boundaries, not burning bridges.

This journey has been a lesson in balance, in learning to guard my personal space while navigating the demands of a professional world that increasingly infringes upon it. It’s a tightrope walk many of us are familiar with, especially in this digital age. I belive my experience will inspire others to take charge of their boundaries, to remember that it’s okay to say no and to do so with kindness and firmness.

In the end, it’s not just about warding off unsolicited calls. It’s about preserving a sense of self, maintaining a work-life balance, and ensuring that our mobiles serve their true purpose: keeping us connected to what truly matters.

The Power of Quality: Why Your Software Needs More Than Just Correctness

When developing software, many people focus on one aspect above all others: functional correctness. While this is an important aspect of software development, it’s not the only one. Two other vital elements should be considered: software quality and software testing.

So what is the difference between software quality and testing, and why are they so important? Let’s take a closer look.

Software Quality

Software quality refers to the overall quality of a piece of software, considering factors such as reliability, maintainability, and usability. In other words, it’s about more than just whether the software works correctly or not. It’s about how easy it is to use, how easy it is to maintain and update, and how reliable it is over time.

High software quality requires careful planning and attention to detail throughout software development. It includes everything from writing clean, well-organized code to designing intuitive user interfaces to rigorously testing the software to ensure it meets all its requirements.

Software Testing

On the other hand, software testing is focused explicitly on verifying that the software works correctly and meets all its requirements. The process involves designing and executing test cases that exercise the software in various ways to ensure it behaves as expected.

While software testing is integral to software development, it’s important to remember that it’s just one part of the process. There needs to be more than testing to ensure high-quality software. You must take a holistic approach that includes careful planning, design, coding, and testing to achieve that.

Why It Matters

So why is focusing on software quality rather than just functional correctness so important? The answer is simple: because software is rarely used in isolation. In most cases, it’s part of a more extensive system that includes other software components, hardware components, and human users. As a result, if the software is difficult to use, unreliable, or hard to maintain, it can negatively impact the entire system.

For example, imagine you’re using a piece of software that is difficult to use and prone to crashing. Even if the software technically meets all its functional requirements, it will still be frustrating and time-consuming to use. In addition, it can have a ripple effect throughout the entire system, slowing down other processes and potentially causing errors or delays.

By focusing on software quality and not just functional correctness, you can ensure that your software is reliable, easy to use, leading to a better overall user experience and more successful outcomes.

Summing up

While functional correctness is an essential aspect of software development, it’s not the only one. To truly ensure that your software meets the needs of your users, you need to focus on software quality and testing. By taking a holistic approach to software development, you can help ensure that your software is reliable, easy to use, and easy to maintain, leading to better outcomes for everyone involved.

The Price of Chaos: Balancing Standardisation and Creativity in Software Development

As a software engineer, I once worked for a large organisation that was experiencing continuous growth. However, I found myself in the midst of a chaotic environment where every team was using a different programming language and framework. While the situation seemed exciting initially, it soon became apparent that it was unsustainable. As the number of projects grew, the cost of maintaining all these different technologies began to spiral out of control.

As a solution, the company’s technical leaders decided to standardise on a single programming language and framework across all projects. The benefits were clear: reduced maintenance costs, improved collaboration and better knowledge sharing. It was a no-brainer, right?

Well, not quite. While standardisation can effectively reduce costs and improve delivery speed, it can also harm creativity and innovation. As software engineers, architects and technical leaders, we must know the potential trade-offs and take a measured approach when considering standardisation.

On the one hand, standardisation can help with cost reduction by reducing the number of technologies needing maintenance. But on the other hand, it can also speed up delivery by allowing teams to share knowledge and resources more efficiently. As a result, it can benefit large organisations with many teams working on different projects.

However, standardisation can also stifle creativity and innovation. When we limit ourselves to a single programming language and framework, we may miss out on new ideas and approaches that could lead to project breakthroughs. We may also lose talented engineers who prefer to work with different technologies. As technical leaders, it’s essential to balance standardisation and creativity.

So, what can we do to strike this balance? Here are a few tips:

Consider your organisation’s needs: Every organisation is unique, and there is no one-size-fits-all solution. Consider the size of your organisation, the number of projects you have, and the resources available when deciding whether or not to standardise.
Involve your team in the decision-making process: Your team members are the ones who will be working with the chosen technology daily, so involve them in the decision-making process. It will help ensure that the chosen technology is a good fit for your team and that they are motivated to work with it.
Allow for experimentation and innovation: Even if you choose to standardise, it’s essential to allow for experimentation and innovation. Encourage your team members to try new tools and approaches and be open to new ideas and suggestions.
Keep an eye on emerging technologies: The technology landscape is constantly changing, so keep an eye on emerging technologies that may be relevant to your organisation. Feel free to explore new technologies and incorporate them into your tech stack if they make sense.

In conclusion, standardisation can be an effective way to reduce costs and improve delivery speed, but it can also have a negative impact on creativity and innovation. As software engineers, architects and technical leaders, it’s essential to strike a balance between the two. By considering your organisation’s needs, involving your team in the decision-making process, allowing for experimentation and innovation, and keeping an eye on emerging technologies, you can find the right balance for your team and projects. And one day, you too will find yourself in a situation where you must choose between chaos and standardisation!

Easy way to use multiple GIT accounts with SSH keys from single computer

I’ve been using a single machine for multiple GIT accounts. I would often get stuck when trying to push/pull changes while using wrong SSH keys or creating commits with invalid username and email combinations. The last bit was incredibly annoying as I would have to review commit history and amend all invalid commit messages.

I do use the GIT command-line client from my Mac, authenticate over SSH with keys. I also use ZSH shell with Oh My ZSH and the excellent Powerlevel10k theme for ZSH.

Researching articles on the Internet, I didn’t find a solution that would work efficiently for me from the command line. As Oh My ZSH is easy to extend (as I found out after reading a bit of documentation), I created my solution.

Git profile switch in action

The switching functions, git_switch_to_personal and git_switch_to_work perform two tasks:

Switches the files in the .ssh configuration folder to the appropriate SSH keys
Sets up global git configuration with “user.email” and “user.name” parameters.

I also modified ZSH prompt to show me which profile I have set up currently. The same information can be obtained by executing git_what_profile command.

Following are what’s required to get the functionality sorted.

Switching SSH keys and GIT configuration

I created git_switch.zsh file in the ~/.oh-my-zsh/custom/ folder. When a new shell is started, the file is loaded, and new functions become available.

git_switch_to_work() {
  rm -rf ~/.ssh/personal ~/.ssh/work && rm -rf ~/.ssh/id_rsa ~/.ssh/id_rsa.pub
  cp ~/.ssh/id_rsa.work ~/.ssh/id_rsa && cp ~/.ssh/id_rsa.work.pub ~/.ssh/id_rsa.pub
  git config --global user.email "greg.gigon@work-email.com" && git config --global user.name "greggigon-work"
  touch ~/.ssh/work
}


git_switch_to_personal() {
  rm -rf ~/.ssh/personal ~/.ssh/work && rm -rf ~/.ssh/id_rsa ~/.ssh/id_rsa.pub
  cp ~/.ssh/id_rsa.personal ~/.ssh/id_rsa && cp ~/.ssh/id_rsa.personal.pub ~/.ssh/id_rsa.pub
  git config --global user.email "greg.gigon@personal-email.com" && git config --global user.name "greggigon"
  touch ~/.ssh/personal
}

git_what_profile() {
  if test -f ~/.ssh/personal; then
    echo personal
  else
    echo work
  fi
}

The functions assume that I have two pairs of SSH keys in the ~/.ssh/ folder, one with keys I use for authenticating with personal GIT account and second for authenticating with work GIT account.

The function removes the default SSH keys and copies the selected as defaults, id_rsa and id_rsa.pub. Also, functions create empty files, which indicate the active profile.

Adding GIT profile information to the ZSH prompt

To make permanent changes to the prompt, I had to edit ~/.p10k.zsh file.

First, I created the function with the following content:

function prompt_my_git_profile(){
    if test -f ~/.ssh/personal; then
      p10k segment -s PERSONAL -f green -t "personal"
    else
      p10k segment -s WORK -f red -t "work"
    fi
  }

The function checks for the existence of the files indicating the active profile. The file contains an example prompt function; a great to put the newly created function.

I also had to add the element to the prompt by modifying POWERLEVEL9K_LEFT_PROMPT_ELEMENTS variable (at the top of the file).

# The list of segments shown on the left. Fill it with the most important segments.

  typeset -g POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(
      # =========================[ Line #1 ]=========================
      os_icon                 # os identifier
      dir                     # current directory
      my_git_profile
      vcs                     # git status
      # =========================[ Line #2 ]=========================
      newline
      # prompt_char           # prompt symbol
  ) "

Note that the function is called prompt_my_git_profile but when adding it as one of the elements, I had to drop the prompt_ prefix and only use the my_git_profile in the name.

You can adapt the functions to work with more than two profiles.

Enjoy the simple hack.

My Personal Kanban 2.0 Beta, Open Sourced

The year 2020 brought the opportunity to spend time learning new skills. I picked the old pet project, My Personal Kanban and decided to rewrite it with a completely different technology set.

Here it is, version 2.0 of My Personal Kanban. This time, it’s a standalone app, running on MacOS, Linux and Windows.

I’m using the app instead of a real-life Kanban board for my Personal Kanban. If you are not familiar with Personal Kanbans and why they are suitable for Personal Productivity, I recommend this short article with a video explaining why Personal Kanban is excellent.

A bit more about technologies

My Personal Kanban 1.x was a single page web app using local browser storage and suffered from never-ending cross-browser compatibility issues. I also delivered it using Angular 1.x of which I was not a big fan.

As I saw beautiful applications written with Electron framework, including Visual Studio Code or Slack Desktop client, I thought of learning Electron myself.

In the end, I landed the following stack:

Electron – it’s a framework for building cross-platform desktop apps with web technologies. It helped me to focus on building functionality, without worrying about cross-browser compatibility. It also made it easy to write the content of boards to the file system.
TypeScript – it’s a programming language, that brings type system to the power of JavaScript. I spend a lot of time at my job Java or Kotlin, and I like having type system to hand. Also, it was an excellent excuse to learn another language.
ReactJS – it’s a JavaScript library for building User Interfaces. It was not my first contact with React, and I liked it from previous projects. However, this time I used it using functional style.
Material-UI – it’s a library of React Components. I used the included Material Design style.
electron-react-boilerplate – it’s a boilerplate code, including all of the above frameworks (except Material-UI). It gave me a great starting point.

I open-sourced the entire code at GitHub. And you can fetch the latest binaries from the My Personal Kanban 2.0 page.

Please get in touch via GitHub or the comments section if you have ideas about features or improvements to the application.

2.0.0-alpha-1 released, a new version of My Personal Kanban

Second release includes few new features that I was missing when using My Personal Kanban. Some of the features come from suggestions posted by users of the original My Personal Kanban, version 1.0.

My Personal Kanban version 2.0.0-alpha-1

The few main features include:

Limiting WIP
Cards tagging
Unique numbers on tags
Cosmetic changes and additional keyboard shortcuts

I still have some functionality I would like to deliver in the next few releases, including:

More keyboard shortcuts
Exporting/Importing of single board
Filtering of cards on the board by using tags

As before, I would love if you could give me some feedback on the Application.

The detailed description with OS specific downloadable binaries on the My Personal Kanban 2.0 page.

My Personal Kanban 2.0 – new version released

Seven years ago, I released an application that became quite popular with many practitioners of Personal Kanban. I decided it was time to give the app a refresh.

My Personal Kanban 2.0 https://greggigon.com/my-personal-kanban-2-0/

As I was not too fond of the technologies I previously used to create My Personal Kanban 1.0, I decided to re-write the app from scratch using new technologies and creating My Personal Kanban 2.0 as a standalone application.

I picked Electron to achieve portability between multiple platforms and React for the UI framework.

Today, I give you a first version of the My Personal Kanban 2.0, alpha 0. You can download OS-specific binaries from Box. List of binaries at the following page.

In this release, I implemented the following features:

Creation of Boards as well as the removal of boards
Naming of columns
Creating, editing, viewing and deleting of the Kanban cards
Drag and drop of the cards between columns
Boards switching with board buttons
Archiving of cards in the last column
Browsing of card archives with a simple search
Dark and Light theme switching
Keyboard shortcut “Shif+A” for adding a new card
Choice switch, for adding new Kanban card at the beginning or end of the card list in a column
Saving of the content on the disk

Please, provide me with feedback and potential features you would like to see in the next upcoming releases.