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.

How safety at work improves creativity and productivity

I finished 2019 with a short holiday. I used the time to reflect on the journey past year. In December, I was at the “AWS re:Invent” conference. Amongst many sessions, I particularly enjoyed those that focused on Software Engineering processes and practices. During one of the presentations, the speaker said a sentence which very much engraved itself into my mind:

“The most productive and creative work happens in environments where it’s safe to experiment. To get most out of your Engineers, create safety instead of restricting freedom by introducing draconian rules and policies.”

Working for many years in tightly controlled environments, I realised the importance of the above statements. I also realised the many dimensions of safety to which the speaker was referring.

Impact of tight rules and policies

Many organisations, specifically large organisations, introduce regulations and procedures to prevent undesired situations from happening. In my experience as a software engineer, I had to deal with tight controls of Internet access, permissions of my development environment, access to test environments, curated list of software and dependencies.

Those rules were not only frustrating and inconvenient for other developers and me, but were also preventing us from trying new things, improving existing solutions and slowing down the delivery process.

The frustration resulting from the blockers, caused me and my colleagues to find creative ways to work around the restrictions, by “hacking” processes. We wasted our creative efforts on the wrong outcomes.

The sad truth is that regardless of the rules and policies undesired situations happened. Back in the days, you could hear about security mishaps and performance issues on the BBC.

When I think about the quote from the beginning of the post, I know that fruits of my work might have been more creative and take much less time if I would have the freedom to experiment and progress safely.

Safety comes in different shapes and sizes.

As a software engineer, when I talk about safety, I immediately think about safe development environments where I will cause no harm to the production systems. However, there is another dimension to it: a safe environment in a company, where:

it’s fine to voice opinions and raise concerns
there is no prejudice, bias or harassment
no blame is assigned.

No amount of technical solutions will make a difference in your organisation unless you make people feel safe to express their thoughts honestly and openly.

How to create safety

road_block_driving_safety

As leaders and managers, we create a safe environment by being transparent and open. When our people realise they don’t have to worry about speaking their mind and challenging current approaches, they would have time to focus on existing work and bring ideas for improvements.

Safety is a feeling, and different people might feel it differently. It might take time, and a different approach before people in your team feel safe. Start by asking yourself, what would/is making you feel safe at work? Adopt it as your behaviour towards others and iterate on the approach. I find it useful to get feedback on my methods during 1-2-1s.

When it comes to technical solutions, the following are some ideas on safety for experimentation:

Managed developer desktops, with no access to the corporate network, with permissions to add additional software at will
Sandboxed dev environments with no connection to delivery pipelines
Separate Internet access without restrictions on the development resources
Production-like data for experiments

Following ideas are for safety in the delivery work, as a part of development practices :

Automated functional and non-functional testing
An automatic, no-human-touch deployment pipeline
Reproducible environments
Configuration as code

I know that the last few points are essential DevOps practices. It’s not coincidental as they are designed for safety due to the fast-paced nature and the elimination of human error.

Remember, keep your workplace “safe”!

Naming things is hard … and very important

Have you ever watched “The Croods“? When my daughter was younger, I watched it many times. The Croods are family of a caveman trying to survive another day in the dangerous, prehistoric world. There is no doubt in the entertaining value of the movie, but the thing that I remembered the most are the scenes where cavemen are attempting to name new “things”. I always wondered how did they come up with names for things, how come “wheel” is a wheel? It is difficult even to imagine the thought process. Why not try yourself? Think of a different name for a “wall”.

800px-English-English_and_English-Persian_dictionaries

Naming things is hard. It’s even harder when you have to do it regularly during the day. If you are somehow puzzled to what profession requires to continually come up with proper names for things throughout the day, let me put you out of your misery; it is Software Developer or Software Engineer.

When creating software, developers have to name: variables, functions, objects, modules, systems, classes, etc. All of them would have behaviour, which requires a proper name as well. Proper naming is crucial because:

it communicates meaning
it helps collaborate
reduces time and cost of maintenance

Working with a team means that developers have to collaborate and incorporate each-others code in their work. They need to understand the meaning of the code, intention and behaviour to incorporate it within their work correctly.

Naming things in Software

Today, computer programs can contain thousands if not millions of lines of code. Without code being transparent, it is hard to modify it, change it, improve it. The naming of different elements of code is a massive part of making code clean.

Each programming language has its own set of conventions and practices when it comes to naming. Following those standards provides a mental shortcut and reduces cognitive load during the development process.

Naming standards are also crucial for aspects of the development process itself. Thanks to the common understanding of words and phrases like “build” and “release”, or “story” and “feature”, we know how to work with each other.

Naming things in the Development Flow

When working with code, we collaborate using Version Control Systems. The one that is the most popular at the moment is Git. Few services are offering Git repository hosting, with GitHub being defacto golden standard in the industry.

branches

Git is quite flexible with the ways of using it; however, teams typically adopt one of the standard models. GitHub or Atlassian has a great set of posts explaining the different models. The model that seems the most suitable for the Enterprises that worked 90% of the time for the teams in companies I worked for seems to be GitFlow. The flow prescribes names for branches. Those names are relevant as of the points mentioned above in my post. Branch names help with the understanding of:

where to put code that is Work in Progress
where to integrated completed code
where to stage code ready for creating a release candidate
where to put code that is officially released and in production
where to put code that fixes issues and bugs

I do like to make it easy for people to do the right thing and hard or impossible to do the wrong thing. Hence I created a little GitHub Application, that looks after names of branches in the repository and raises an issue if the name is wrong or deletes the offending branch.

You can check it out at https://greggigon.com/brunchyyy and https://github.com/greggigon/brunchyyy.

Final words

Correct naming is essential in software development. Naming standards provide mental shortcuts, reducing cognitive load. They also provide a shared vocabulary for communicating and building blocks of understanding. Pay attention to naming and help your teams adopting standards.

I’m going to leave you with this funny short Clip from “The Croods” illustrating how hard it could be to name things correctly 🙂

Beginning of the writing challenge

Today I’m starting my twenty stories writing challenge. Inspired by a friend of mine, who recently started hers, I will be writing in the next 20 posts, about my experiences in the world of Technical Leadership. I attempt to produce new content at least once every three weeks.

My reasons for challenging myself are:

I lost my passion for writing, and I would like to rekindle the fire
I would like to share some useful tips for Technology Leaders who, like me are struggling in the traditionally non-tech industries
I’m hoping to use the challenge as a way of documenting experiments in management and leadership. I will share the results and lessons learned

This post doesn’t count as part of the challenge. Within the next 3 weeks, I will produce the first post.

challenge

Let the challenge begins.