Personality theories provide a blueprint for understanding why people behave the way they do. In the latest edition of our State of the Developer Nation 22nd Edition – Q1 2022, we incorporated a measure of the widely accepted ‘Big Five’ personality dimensions. We did this in order to better understand the personality traits of software developers. Here, we share some of our findings on developer personalities. Our aim is to discuss how this kind of information can help to support interactions with developers.
Personality measures are a powerful tool for understanding people’s preferences and behaviours. Software teams need diversity not only in terms of skills, experience, and knowledge, but also require a variety of personalities. This will help teams collaborate effectively on complex and challenging projects.
The Ten-Item Personality Inventory
We used the Ten-Item Personality Inventory (TIPI) methodology in order to measure the ‘Big Five’ personality dimensions. These dimensions are: emotional stability, extraversion, openness to experiences, agreeableness, and conscientiousness. The TIPI method is well-suited for situations where short measures are required. The results have been shown to have good alignment with other widely used Big Five measures1. Although more comprehensive and accurate personality measures than TIPI exist, they typically require an entire survey to themselves.
The TIPI method presents respondents with ten pairs of personality traits and asks them to rate how strongly these traits apply to them. Below, we show responses to these items for over 12,000 developers. We find that developers, in general, see themselves as complex and open to new experiences (86% agree or strongly agree that this applies to them), dependable and self-disciplined (79%), calm and emotionally stable (76%), and sympathetic and warm (74%).
Diving deeper into the TIPI data allows us to identify more specific personality types within the general developer population. We collapsed these ten items into five distinct measures, one for each of the Big Five personality dimensions. For example, statements about being ‘sympathetic, warm’ and ‘critical, quarrelsome’ combine to give an overall measure of agreeableness. We then derived a score for each developer on each of the five dimensions. This helped us identify the developer personalities at the polar ends of each dimension, e.g. labelling those who are at the top end of the agreeableness scale as ‘agreeable’ and those at the bottom end as ‘disagreeable’.
Finally, we segmented all developers into a set of distinct personality types. We did this by using the personality labels that they had been assigned as inputs to our segmentation algorithms.
Approximately 8% of all developers differ from the aforementioned group. They showcase a higher level of openness to experiences – often related to intellectual curiosity. These software developers have personality traits that suggest they are likely to investigate new tools and technologies. They are also more likely to stay up to date with the cutting edge of technology.
The Five Developer Personalities
The following charts show the characteristics of five example developer personalities revealed within our data. A well-rounded, ‘balanced’ personality type accounts for 52% of the developer population. These are developers who sit firmly at the centre of each dimension. They are neither introverted nor extroverted, highly agreeable nor disagreeable, emotionally unstable nor lacking emotion, etc.
5% of developers fit a ‘responsible and cooperative’ personality type. These developers score highly in conscientiousness, openness to experiences, and agreeableness in comparison to the majority of developers. Increased conscientiousness often relates to setting long-term goals and planning routes to achieve them, e.g being career-driven. Higher scores for openness to experiences reflects a preference for creativity and flexibility rather than repetition and routine. Our data backs this up. These developers are more receptive to personal development-related vendor resources. For example, 35% engage with seminars, training courses, and workshops compared to 25% of ‘balanced’ developers. Their high scores for agreeableness also correlate with greater engagement with community offerings. For example 23% attend meetup events compared with 17% of ‘balanced’ developers.
5% of developers conform to an ‘achievement-driven and emotionally stable’ profile. As with the previous personality type, they are conscientious and open to experiences. However, they score much higher in terms of emotional stability but slightly lower in terms of agreeableness. Developers who score high in emotional stability react less emotionally. For example they favour data over opinions. Lower agreeableness can be a useful trait for making objective decisions, free from the obligation of pleasing others.
We also find a segment of developers with an ‘introverted and unreliable’ profile. They indicate that they are less involved in social activities, disorganised, closed to new experiences, and less agreeable than other developers. Fortunately, these developers, who are likely hard to reach and engage in new activities and communities, are a very small minority, at 2% of all developers.
Developer Personalities, Roles and Content Preferences
Finally, we show how the characteristics of these developer personalities vary, in terms of both associations with developer roles and the kinds of information and content that they consume. Developers in the ‘balanced’ profile are most likely to have ‘programmer/ developer’ job titles. However, those who fit the ‘responsible and cooperative’ profile are disproportionately more likely to occupy creative (e.g UX designer) roles. This aligns with their increased creativity/openness, and senior CIO/CTO/IT manager positions, reflecting their self-discipline and achievement striving.
Those who are ‘achievement-driven and emotionally stable’ are less likely than other personality types to have ‘programmer/developer’ job titles, but disproportionately more likely to be data scientists, machine learning (ML) developers, or data engineers. They tend to deal mainly in facts and data rather than opinions and emotions. Those in the ‘introverted and unreliable’ profile are more likely to have test/QA engineer and system administrator job titles than those in other personality types.
When it comes to where developers go to find information and stay up to date, perhaps unsurprisingly, the ‘introverted and unreliable’ personality type uses the fewest information sources overall, affirming that they are a difficult group to engage via community-focussed events and groups. However, their use of social media is in line with other personality types, suggesting that this may be a suitable channel for catching the attention of this hard-to-reach group.
Both of the high-conscientiousness and high-openness personality types use the widest range of information sources overall, however, those who are more cooperative are considerably more likely to turn to social media for information about software development (53% of the ‘responsible and cooperative’ type vs. 44% of the ‘achievement-driven and emotionally stable’ type).
‘Intellectually curious’ developers are the most likely to make use of official vendor resources and open source communities. Hence, the audience that vendors reach via these resources may be slightly more keen to experience new products and offerings, than the typical ‘balanced’ developer.
What’s Next with Developer Personalities
We just began to scratch the surface of developers’ personality profiles. The personality types we have shown are indicative of just a few of the differences that exist among developers. By capturing this kind of data, we’ve opened the door for more extensive profiling and persona building, along with a deeper analysis of how the many other developer behaviours and preferences that we track align with personality traits. If you’re interested in learning more about developer personalities and how this can help you to reach out to developers, then we’re very excited to see how our data can support you.
In this article, we’ll be learning about the basics of the data storage mechanism for git.
The most fundamental term we know regarding git and data storage is repositories. Let’s first understand what a git repository is and where it stands in terms of data storage in git.
Are you ready to influence the tech landscape? Take part in the Developer Nation Survey and be a catalyst for change. Your thoughts matter, and you could be the lucky recipient of our weekly swag and prizes! Start Here
Repositories
A git repository can be seen as a database containing all the information needed to retain and manage the revisions and history of a project. In git, repositories are used to retain a complete copy of the entire project throughout its lifetime.
Git maintains a set of configuration values within each repository such as the repository user’s name and email address. Unlike the file data or other repository metadata, configuration settings are not propagated from one repository to another during a clone, or fork, or any other duplication operation. Instead of this, git manages and stores configuration settings on a per-site, per-user, and per-repository basis.
Inside a git repository, there are two data structures – the object store and the index. All of this repository data is stored at the root of your working directory inside a hidden folder named .git. You can read more about what’s inside your .git folder here.
As part of the system that allows a fully distributed VCS, the object store is intended to be effectively replicated during a cloning process. The index is temporary data that is private to a repository and may be produced or edited as needed.
Let’s discuss object storage and index in further depth in the next section.
Git Object Types
Object store lies at the heart of the git’s data storage mechanism. It contains your original data files, all the log messages, author information, and other information required to rebuild any version or branch of the project.
Git places the following 4 types of objects in its object store which form the foundation of git’s higher-level data structures:
blobs
trees
commits
tags
Let’s look a bit more about these object types:
Blobs
A blob represents each version of a file. “Blob” is an abbreviation for “binary big object,” a phrase used in computers to refer to a variable or file that may contain any data and whose underlying structure is disregarded by the application.
A blob is considered opaque it contains the data of a file but no metadata or even the file’s name.
Trees
A tree object represents a single level of directory data. It saves blob IDs, pathnames, and some metadata for all files in a directory. It may also recursively reference other (sub)tree objects, allowing it to construct a whole hierarchy of files and subdirectories.
Commits
Each change made into the repository is represented by a commit object, which contains metadata such as the author, commit date, and log message.
Each commit links to a tree object that records the state of the repository at the moment the commit was executed in a single full snapshot. The initial commit, also known as the root commit, has no parents and the following most of the commits have single parents.
A Directed Acyclic Graph is used to arrange commits. For those who missed it in Data Structures, it simply implies that commits “flow” in one way. This is usually just the trail of history for your repository, which might be very basic or rather complicated if you have branches.
Tags
A tag object gives a given object, generally a commit, an arbitrary but presumably human-readable name such as Ver-1.0-Alpha.
All of the information in the object store evolves and changes over time, monitoring and modeling your project’s updates, additions, and deletions. Git compresses and saves items in pack files, which are also stored in the object store, to make better use of disc space and network traffic.
Index
The index is a transient and dynamic binary file that describes the whole repository’s directory structure. More specifically, the index captures a version of the general structure of the project at some point in time. The state of the project might be represented by a commit and a tree at any point in its history, or it could be a future state toward which you are actively building.
One of the primary characteristics of Git is the ability to change the contents of the index in logical, well-defined phases. The indicator distinguishes between gradual development stages and committal of such improvements.
How does git monitor object history?
The Git object store is organized and implemented as a storage system with content addresses. Specifically, each item in the object store has a unique name that is generated by applying SHA1 to the object’s contents, returning a SHA1 hash value.
Because the whole contents of an object contribute to the hash value, and because the hash value is thought to be functionally unique to that specific content, the SHA1 hash is a suitable index or identifier for that item in the object database. Any little modification to a file causes the SHA1 hash to change, resulting in the new version of the file being indexed separately.
For monitoring history, Git keeps only the contents of the file, not the differences between separate files for each modification. The contents are then referenced by a 40-character SHA1 hash of the contents, which ensures that it is almost certainly unique.
The fact that the SHA1 hash algorithm always computes the same ID for identical material, regardless of where that content resides, is a significant feature. In other words, the same file content in multiple folders or even on separate machines produces the same SHA1 hash ID. As a result, a file’s SHA1 hash ID is a globally unique identifier.
Every object has an SHA, whether it’s a commit, tree, or blob, so get to know them. Fortunately, they are easily identified by the first seven characters, which are generally enough to identify the entire string.
One fantastic benefit of saving only the content is that if you have two or more copies of the same file in your repository, Git will only save one internally.
Conclusion
In this article, we learned about the two primary data structures used by git to enable data storage, management, and tracking history. We also discussed the 4 types of object types and the different roles played by them in git’s data storage mechanism.
This was all for this article, I hope you find it helpful. These are the fundamental components of Git as we know it today and use on a regular basis. We’ll be learning more about these Git internal concepts in the upcoming articles. Keep reading. In case you want to connect with me, follow the links below:
Choosing a programming language can be complicated as many aspects need consideration. You might wish it was as easy as choosing between various flavors of ice cream or pizza. Ask any developer or technical manager to understand what drives popular choices in the tech world. In this article, you can learn what drives a choice of programming languages and the data-driven decisions developers should take to safeguard their careers while ensuring success in the projects they deliver.
Technology changes rapidly in today’s digital race, and the chosen language must get future potential to remain in use with strong developer communities, or else organizations can face maintenance and integration issues. Even young developers are keen to know which languages have excellent career potential, so they invest their time wisely.
Young developers may make the mistake of choosing a programming language because it’s trendy and cool. As a young developer, you can avoid these mistakes by referring to various tech forums and authentic sources like Slashdata’s – 22nd edition of The State of the Developer Nation (Q1 2022) that offer insights into popular programming languages and their growth trends.
Choosing a programming language
The choice of a programming language gets intertwined between your career aspirations and work experience. You learn a programming language and need to work on projects to gain relevant industry experience. So as a developer, you need to have a holistic approach to choosing a suitable language.
Choosing a programming language depends on various factors, and you should know all the components to get a better view and then make a choice. A good selection of programming languages will lead to spending less time on scaling, maintenance, and other aspects like security in projects.
Here are some typical questions you must ask when choosing a programming language for a project.
Does the programming language have proper community ecosystem support? Is it going to work over the long term? Is vendor support available?
What is the type of environment for the project – web solution, mobile, cross-platform, etc.?
Are there any infrastructure considerations like new hardware or particular deployment needs?
What do the clients prefer?
Are there any specific requirements for the programming language’s libraries, tools, or features?
Are experienced developers available for the programming language?
Are there any performance considerations, and can the language accommodate this performance?
Is there a security consideration or requirement for any third-party tool?
It would help if you remembered that irrespective of the chosen programming language, you can write good or bad code with any language. Besides the typical questions above, it’s advisable to consider a few critical factors in-depth before choosing a programming language. In programming, adherence to widely accepted design principles and philosophies is essential.
Some critical considerations driving the choice of a language include the following:
1. Type of application
The type of application varies from complicated embedded firmware to web and mobile. Common programming languages like Java, Python, JavaScript and C# can build different types of applications on various platforms. There are also situations where specific languages work better. With the rise in mobile apps, for example, you would choose Java for building a native Android app or a C and C++ combination for an embedded firmware project.
2. Complexity of applications
Identifying the application’s size and complexity helps determine the choice of programming language. The smaller and simple applications like marketing websites or webforms can use content management systems (CMS) like WordPress that may need minimal programing. On the other hand, complex applications like e-commerce websites or enterprise applications or emerging technology applications like IoT devices or AI-based applications may require Java or C#. As a technical manager, you can be an expert in gauging complexity with various experiences.
3. Organization culture
The choice of Open source technologies vs. proprietary software tends to rest with the organization’s culture and a direction often set by management. All programming languages have a trade-off, and some companies may choose one that is scalable, while others may pick one that has a shorter learning curve and is easy for the developers. Whatever the culture, the priority should be on choosing a language that optimally addresses the project needs. You can easily understand an organization’s choice once you start working on their technology stack.
4. Time to market:
Businesses rely on getting their product to the market early for competitive gains. Choosing new programming technologies and languages is better for a project with longer timelines. You can complete your project faster by leveraging the developers’ existing skills. For example, if you already have an AWS-based cloud environment and relevant team expertise, it will be quicker to work on it than move to another technology environment.
5. Maintainability
Technology stacks have their library ecosystems and vendor support. Choose a programming language with regular update releases that will stay current for some time. Maintaining the codebase is essential, and maintenance costs depend on the availability of developers. For example, as per today’s trends hiring Java, C#, Python, or PHP developers is easy and cost-effective. Organizations can make a data-driven decision by looking at the size of programming language communities from various industry reports from Slashdata.
6. Scalability, performance, and security:
The performance of the application depends on your choice of programming languages. It becomes essential when the development environment has limitations on scaling. Some popular tech stacks with great scalability include Ruby on Rails (RoR), .NET, Java Spring, LAMP, and MEAN.
It would be best if you protected applications from cyber threats. Following the security guidelines are crucial before choosing any programming language for your application. For example, a financial application needs PCI compliance, while healthcare-related applications need HIPAA compliance. Your choice of programming languages must be able to deliver application compliance.
Insights – Slashdata – 22nd edition of The State of the Developer Nation (Q1 2022)
You know the factors that drive the choice of programming languages. Let us look at findings from the Slashdata – 22nd edition of The State of the Developer Nation (Q1 2022). It offers exciting statistics that can help you as a developer know if your skills are up to date or need an upgrade.
JavaScript remains the most prominent language community, with close to 17.5M developers worldwide using it.
Python has remained the second most widely adopted language behind JavaScript, with the gap between the two largest communities gradually closing. Python now counts 15.7M users after adding 3.3M net new developers in the past six months alone.
The rise of data science and machine learning (ML) is an apparent factor in Python’s growing popularity. About 70% of ML developers and data scientists report using Python versus only 17% using R.
Java is one of the most critical general-purpose languages and the cornerstone of the Android app ecosystem. Although it has been around for over two decades, it is experiencing strong and steady growth. Nearly 5M developers have joined the Java community since 2021.
Data shows that Java’s growth gets fueled by the usual suspects, i.e., backend and mobile development, and its rising adoption in AR/VR projects.
Wrapping up
We hope you have more clarity and data-driven insights in choosing programming languages for your career and projects. We encourage you to regularly read the whole SlashData – 22nd edition of The State of the Developer Nation (Q1 2022) report and stay updated on trending technologies.
Crypto, Blockchain and Web3 are buzzwords these days and while you might already hold some Bitcoin on Coinbase or Binance, you might also be wondering how you can move your career into this new industry as a developer.
Good blockchain developers are highly sought after and becoming an expert in these new technologies can bring you an exceptionally high income as well as job security.
It’s easy to google “How to become a blockchain developer” to find out what technical skills you will need and what programming languages you will have to learn. You will find lots of helpful information e.g. here and here.
According to the latest State of the Developer Nation Report, blockchain applications, cryptocurrencies, and NFTs have the highest share of developers learning about them.
More specifically with regards to Cryptocurrencies, out of a sample of 13,939 developers, 50% stated they are interested in them, 34% said they are learning about them while 16 % have already adopted the technology.
But what actually is Crypto, Blockchain and Web3? And – once you have the skills – how are you going to get your foot in the door and create long-term success?
Ecosystem Education
If you are a complete newbie, I’d suggest educating yourself on the origins and philosophy of bitcoin and blockchain first, as well as the evolution of Web3. There are some great free courses that will give you a solid foundation and might help you find a niche to focus your efforts on.
UnitMasters.org for example is an engaging 6-week course that will give you a good high-level overview of the Web3 ecosystem. It is very welcoming to participants from all walks of life and underrepresented backgrounds.
The free MOOC on Digital Currencies by the University of Nicosia, which is taught by prominent bitcoin educator Andreas Antonopoulos, is a great place to start if you really want to understand how bitcoin works and why it is here.
Crypto Job Boards
There are a number of job boards dedicated to Web3, but simply submitting your CV has never been the best way to go about this, in my opinion. Nevertheless, it’s helpful to know about them, so here are a few you can check out:
The best positions are often filled before they make it to a job board, since candidates are being hired from within the network of the recruiter or the organization hiring. That’s why it is important to connect with others in the space. If the term “networking” makes you cringe or sounds like a chore to you, here are some easy ways to go about that:
Attend crypto meet-ups or blockchain conferences to learn about all the things that are being built in this space. You’ll be amazed what some teams are creating out there and you will surely find something that excites you, or sparks your own ideas.
Join the online communities of the projects that you are most interested in. Most of them have a Discord community, which you can find on their websites. Start chatting with other developers in there who may be looking for team members and look out for vacancies in their announcement channels.
Start using some DApps (Decentralized Applications) – whether it’s a simple wallet to send and receive cryptocurrency or blogging platforms like Hive that allow you to earn cryptocurrency for your content. If you’re a gamer, check out games like Splinterlands or Axie Infinity. It’s easiest to start with something you already know.
No matter what your background is, begin using Web3 apps so you gain personal experience as a user. This will help you learn about their challenges or short-comings and you can begin thinking about solutions for them – whether it is UX design or their token economy. You could begin contributing to their improvements, or you could join (or create) a team that will build something better.
Many people get hired by companies because they have proven their knowledge, engagement and contribution in their communities already.
Web3 projects don’t hire staff, they recruit members.
This goes not only for other stakeholders like customers, users, block producers and investors. Crypto projects are win-win-win communities. All stakeholders are equally important in their contributions to help the project succeed.
4. Join Hackathons and coding bootcamps. Stay in touch with the people you meet there. They might all end up in different projects, so this is a great way to build your professional network.
5.Start creating content! Whether it’s your own blog, a Hive account, or your Github account. Begin creating a public track record of your thoughts or technical contributions to the space.
“Don’t trust. Verify.” This famous crypto slogan applies not only to the blockchain but also to you. Creating a verifiable track record is worth so much more than a fancy CV. Your track record will speak for itself and send projects your way, rather than you having to look for them. Project teams don’t care about your CV, they care about your proven experience and contributions to the industry.
6.Join a DAO and see how you can begin contributing. DAO’s – Decentralised Autonomous Organisations – are an essential part of the Web3 space and might just become the way we will all work and organize ourselves in the future. You can submit proposals and get your contributions funded by the DAO’s treasury, if your fellow DAO members vote for it. Check out LobsterDAO or HerDAO (for womxn developers)to get started.
7. Check out Gitcoin where projects post small tasks that you can earn cryptocurrency for. It will help you build a track record, too.
Community Is The New Currency
Everything in the crypto and Web3 space revolves around communities. There is very little of the top down structures you may be used to. The value of crypto tokens comes from their community of developers and users, and you will also end up choosing your project by the community it already has, or the potential it has to create one. (Are they building something that you think will be adopted by a large number of people? Is it going to make a difference to anyone?)
Make Everyone Want To Work With You
You may be highly intelligent, but intellectual intelligence is not the only ingredient for success. You can be a genius, but it will be of little use if nobody likes working with you.
Emotional intelligence is a highly important part in communities. Web3 is all about “we” rather than “me”. People like to surround themselves with people they like and get along with. Even though everyone can code from their bedroom or a hammock on a remote island these days – be kind, be agreeable, be generous in your communication with others. Online and offline. Be a team player. Be someone that CEO’s, investors and HR or customer service staff enjoy working with.
Making interpersonal communication skills just as important as your technical skills will help you become a highly valued and sought-after contributor and create lasting success!
Already a developer interested in Blockchain? Take the Developer Nation survey, share your views on new technologies, tools or platforms for 2023 and shape the future of the Developer Ecosystem. You will get a virtual goody bag with free resources, plus a chance to win an iPhone 13, a Samsung Galaxy S22, Amazon vouchers and more. Start here
Anja Schuetz is an Operations Management Consultant who has worked for several crypto wallets and blockchain projects. She also mentors first-time crypto investors and helps newcomers move their careers into Web3. Learn more about Anja at https://linktr.ee/consciouscrypto
Developer Nation is continuously trying to bring high quality articles for your career path and your company/organisation among insights, tips, interviews and more from the developer ecosystem. This time we have the honour to host an article by IOD about roles, career growth and leadership, focusing on Cloud, SRE, and DevOps Experts.
This article was contributed by IOD. IOD is seeking new tech bloggers. If you are a top notch tech expert or a writer, join IOD’s talent network and share your expertise!
Today, every company is leveraging technology to innovate, streamline operations, and create value for their customers. Regarding software engineering, developers have a natural and prominent role in creating new capabilities and opportunities, but that cannot happen without a greater support infrastructure. Cloud, SRE (site reliability engineering), and DevOps engineers are central to value delivery and business continuity. It is vital for engineering managers to understand how they can become mentors in order to coach and upskill these experts to both enable their career growth and increase business value.
Distinctions Between Expert Roles
Modern software development teams work in a DevOps way, by bringing people with different competencies together and enabling a faster, higher-quality value delivery and development lifecycle.
Writing the application business logic is only part of the engineering equation needed to deliver customer value. The other part, operations, includes many tasks that are mostly driven by Cloud, SRE, and DevOps experts. Good examples of those tasks are designing scalable and reliable systems, ensuring that code can be tested and deployed using continuous integration and delivery pipelines, monitoring system health, and implementing security and compliance guidelines.
Personally, I dislike the title “DevOps Engineer,” because DevOps is applicable to the entire engineering team and is a more abstract concept. SRE, on the other hand, is a concrete implementation of the DevOps philosophy—experts in an SRE role bridge the gap between developers and operations. A DevOps engineer (what I prefer to call the “automation/cloud specialist”) differs from an SRE, as they only focus on systems operations.
There are some natural derivations in lateral roles that come from further specialisation in certain technology areas such as DevSecOps engineer, chaos engineer, or cloud and solution architects at more senior levels.
SRE and cloud specialists are crucial to the success of the product or service. Yet, they are too often disconnected from the business reality; this is where coaching and mentoring makes all the difference.
Mentoring Is Vital to Career Growth
Engineering managers have the lead role in mentoring and coaching these experts: guiding, providing feedback, showing different career possibilities, and building bridges within the rest of the organisation. Engineering managers can act as human routers to make the connection between experts and business stakeholders, ensuring experts get first-hand knowledge and visibility on the value and end-user experience of the product(s) and service(s) that they work on.
Similarly, managers can then demonstrate to stakeholders the positive business impact of these experts’ actions. Does the solution have a great reliability track record and always meet the agreed SLAs? Tell them about it! What would it take to enable solution architecture to scale ten-fold and be available in other geographical locations to support new business cases? Great conversation starter!
How to Make It Happen
Unfortunately, business stakeholders usually only connect with these experts when something goes wrong (e.g., a system failure), and need to understand what happened and why. Engineering managers can change this pattern and create a new paradigm.
Here are a few things managers can do to establish this paradigm and foster its culture:
Translate business and industry-specific jargon into technical concepts, examples, and terminology that experts can relate to.
Help experts develop the necessary non-technical skills to communicate effectively, and translate complex engineering scenarios into simple, relatable terms and ideas with business impact.
Facilitate sessions where experts can present and showcase potential opportunities that new cloud and data technologies can unlock in the organisation, generating new business models or streamlining existing operations and processes.
Create and explore opportunities for experts to shadow and connect directly with colleagues in different roles across the organisation, such as working alongside a customer support representative or joining a sales meeting.
This enables constructive cooperation across competencies, breaking silos while helping these experts grow and gain a better understanding of their impact in the organisation.
Upskilling, Community, and Thought Leadership
There is no substitute for hands-on learning, and engineering managers have a unique role in creating those opportunities. It’s important to maintain a continuous dialog to understand the expert’s career goals and interests, while simultaneously facilitating situations that enable them to gain new hands-on experience.
Simple and small steps, such as inviting them to a steering meeting, participating in a technical brainstorming workshop, or joining a new, exciting project (even if in a minor role) can make a huge difference and impact. Venturing out of one’s comfort zone is always an opportunity to grow and learn.
Further, hands-on experience should always be accompanied by other learning and input, such as insights from other experts, industry certifications, or non-technical skills development.
Certifications and Digital Content
Consuming digital content—articles, videos, whitepapers—and pursuing industry certifications—such as those offered by AWS, Microsoft, Google, and the Cloud Native Computing Foundation—are both excellent practices for validating existing knowledge and discovering new services, expert insights, and best practices.
Each of these organisations offer certifications that go from the fundamentals to complex solution architecture scenarios, focusing on areas such as security, networking, and data engineering. When combined with hands-on experience outside of typical work tasks, content-learning and certifications provide natural upskilling and specialisation pathways that stay with the expert even when changing jobs or companies.
There are also plenty of advantages to an organisation that has certified experts. It nudges the organisation toward good practices and ways of working, while enabling the company to level up their cloud partnership status and showcase their expertise to customers.
Technology Communities
In organisations, from SMBs to larger corporations, there is a natural tendency for individuals to become siloed in their team and/or business unit. Cloud, SRE, and DevOps are domains transversal to all development teams and organisational structures. Fostering an internal technology community where these experts can regularly meet increases alignment and promotes a healthy exchange of ideas. Moreover, it enables these experts to drive the technology governance and foster a culture of engineering excellence across the organisation.
Similarly, external communities and events are also a great way to gain new insights and fresh perspectives. DevOpsDays, ServerlessDays, as well as AWS and Azure Community Days and Meetups, to name a few, are fantastic options to learn and meet like-minded people. With practically all events now fully virtual and often free to attend, this is something that should be highly encouraged and promoted in your organisation.
Sharing Experiences and Thought Leadership
Engineers, especially less experienced ones, might be intimidated at the prospect of sharing their insight and experiences in technical articles or public speaking engagements. Regardless of the level of the content, whether beginner’s guides or more advanced deep dives, there is considerable value in creating content and sharing knowledge. Entry-level content from a Cloud, SRE, or DevOps expert can offer tremendous value to a developer or business stakeholder not familiar with the topic, and it can help bridge gaps between different competencies.
From a career growth perspective, an expert that invests time and effort in thought leadership activities—including written content and speaking engagements—is more likely to accelerate their professional growth and seniority. This is not first because of the positive visibility that those activities bring to themselves and their organisation (that helps!), but rather, it enables the expert to radically improve and develop valuable communication skills. Simply, with practice comes change; the more we work to translate and express complex thoughts and ideas into written and verbal content, the less subject we are to our own silos.
Conclusion
Coaching and upskilling Cloud, SRE, and DevOps experts reveals new possibilities for impacting how an organisation operates and delivers. With these experts, it’s critical that direct managers and senior leadership start seeing and treating them as essential value creators, not cost centres.
When mentoring these experts, help them understand their potential career paths and growth, and highlight the value they create and the impact they make in the organisation. Most importantly, be transparent, provide constructive feedback, and foster a psychologically safe environment that encourages them to venture beyond their comfort zone and try bringing in new ideas.
We love sharing stories of small teams or even groups of friends getting together and developing innovative products. What’s more interesting is the journey they take as well as the difficulties they face and the learnings they acquire. Today we shed light on the story of a small product team who left their jobs to work on an idea that at first seemed simple but turned out to be quite an adventure! Here is the story of Adopto Bug Fixing – an automated bug reporting tool that helps tech teams receive fast and detailed bug reports.
Our adventure as a startup starts with a product team composed of a product manager, a tech lead, a full-stack developer, a UI designer, a QA tester, and a user researcher. We’ve always shared the desire to build something new to be proud of, so one day we decided to leave the previous company for which we were all working and follow the dream of building our own product-based startup.
“Fall in love with the problem” is the most popular recommendation shared among product people, and those founding a new startup. But here we’re talking about a startup whose 80% is made of builders, people who love to do one specific thing: build solutions. As Dan Olsen once said, “We live in the solution space”, and this is probably the truth when talking about a tech team. So we initially tried to use a shortcut: validating a solution without having validated the problem, as many did before us. We began this adventure with a solution in mind, a leftover from our previous experience, and we tried to look for a fitting problem, and for a market segment that could be interesting. A bit like when you are a child playing with geometric wooden shapes and you try to fit a circle where you should put a square. A true nightmare.
Like many of you surely know, what you should be doing before developing a product, and even more during the very first months of a product-based startup, is NOT building and developing solutions. Your time and energy should be focused on a series of problem discovery activities, ranging from customer interviews, and market research, to competitor analyses. Luckily for us, after banging our heads against a few brick walls, we realized that the solution we were developing wasn’t going far because there was no problem-solution fit, so we hit the brakes and pivoted away.
We braced ourselves with patience and started our quest for a problem that was worth solving and could make us passionate about. “Since we are a product team”, we said, “let’s start exploring some product-team-specific processes”. We deep-dived into processes related to developing new features and those related to the resolution of bugs and technical incidents. Of course, fixing bugs appealed to us much more than developing new sexy features!
We’ve spent the last four months doing customer discovery, interviewing potential customers, talking to them on LinkedIn and Reddit, on Discord channels, and in many product communities active on Slack (p.s. If you ever need feedback on any product you’re working on, I’d suggest getting in Mind The Product, The Product Folks, and The Product Coalition. Everybody is super generous with their feedback and ready to help out). As you can imagine, we had to work against the natural tendency to find shelter in the solution space, especially when at first we couldn’t get many people to talk to. But we managed, mostly because we were scared otherwise we would have to pivot again, and that’s a very painful process, as some of you can surely confirm. So after having chatted with hundreds of people among product managers, customer support reps, and account managers working for companies of various sizes, colors, and shapes, we validated that indeed there is a real problem with bug reporting.
Apart from some specific peculiarities that define every company, the current process that is followed in many places can be simplified like this: bugs (or presumed ones) found by end-users are reported to customer care or customer support, who are then responsible for the thankless task of manually collecting some technical information that is often hard to get -just imagine you need to ask an average user to share the screen and use the browser inspector to be able to check console logs. Then the customer support agent gets to open an issue to report that information in a ticketing system, following a more or less structured process.
This process creates a clear bottleneck: the team responsible for the resolution of the bug receives a report that is usually not very detailed. Not only doesn’t that help identify the steps to reproduce the error, but incomplete reports often lack the technical specs needed to distinguish between a real bug and a device/user-specific error, or even a bad design. This is why, once the ticket is opened, bug reporters and developers initiate a conversation that goes back and forth several times to request the missing details. Sometimes, customer support agents are even forced to reach out again to the end-user to find out more about the bug. This bottleneck is strongly felt by both parties involved: it is an eternal ping-pong that leads to a waste of time, without having any assurance that the bug will eventually be identified and fixed. Here we’ve collected some of the most interesting learnings we gathered on the way. We’d love to share them with you:
1. There is no need for a process…until you actually need one!
The very first thing we learned during our customer interviews is that there is a specific moment when you realize that your team won’t survive if you don’t put in place a somehow structured bug reporting process. We noticed that teams usually move from receiving direct calls or Slack messages from colleagues finding bugs to having a dedicated space to collect all reports. You can have a basic version of this, like a shared spreadsheet, or an #issues Slack channel where the tech team manages to gather all complaints shared by colleagues. Those in need and the bravest, too, even go a step further and build a template to guide colleagues in what details they need to reproduce and triage the bug, so they can quickly define its priority in the backlog.
What are the details that if present speed up the whole bug reporting process?
Where is the bug? – That is, all information that allows the team to exclude problems that are not widespread, but related to certain devices, OSs, browsers, app versions, or even user IDs.
Steps to reproduce – The actions that led the user to find the issue. The golden rule is “the more detailed, the better”. Usually, this information can be obtained only by directly asking the end-user to describe the process they follow that brought them to the bug.
Expected behavior – Bugs are very often unfortunate design choices that produce some friction when using the product. To be able to spot these non-bugs, it’s important to ask the user to clarify what behavior they were otherwise expecting to see.
Technical details – In an ideal world, frontloading helps make the bug resolution process overall more efficient. This is why it is a good practice to immediately collect all those technical details which could later help testers and developers identify the issue, such as network requests, and console logs. When reproducing the bug is not straightforward, details like these come really in handy. Yet, collecting them is a real pain for non-technical colleagues who have to directly ask customers and users. Imagine asking a user to share their screen and activate the Browser inspector so that you can collect the logs. A bit of an extreme situation, especially when dealing with users with low digital literacy.
Priority – The goal is to provide the tech team with an estimation of how quickly they should act on the bug and plan accordingly for the next sprint. This metric can be determined by different factors, such as the number of users that could experience the bug, or the importance of the feature that results affected, but also the impact of the reporting client on the company’s total revenue.
Unfortunately, the truth is that all the effort put into providing colleagues with a template that guides them to report a bug doesn’t always pay off. There will always be someone who won’t follow the suggestions, who prefers to spontaneously make a phone call or send a Slack message directly to the product manager or a developer. And from here we move to the second learning.
2. Templates are useful, but never enough
At least once in our professional life, we’ve all witnessed a colleague who refused to adjust and use a new tool that would have facilitated and sped up not only their work but everybody else’s. This is because the adoption curve for an internal tool of this kind follows the sinusoidal shape of any other technological innovation introduced in the last two centuries (but have a look here to read how the pace is gradually speeding up).
What’s important to bear in mind is that for any new tool or process, there will be one or two colleagues out of ten who will enthusiastically try it out – the so-called innovators and early adopters. Of the remaining eight, though, seven will need to be convinced, pushed, and engaged even just to give it a try, and one-two will likely never accept change. This is the truth, it hurts, but the sooner we accept it, the better.
Chatting with many product managers we identified another point that is very, very painful: even when you have some guidelines about how to estimate a bug priority, non-tech colleagues always report “High priority”.
“Consider, high priority is given even when they are talking about a typo or a misaligned button in the interface of an internal-use-only platform”, many confess with frustration.
This is truly one of those cases where you get nowhere: every team has its own KPIs and success metrics. If we ask a customer support rep, they will say their goal is closing support tickets as fast as possible. If we interrogate an account manager, it is high retention rates and an NPS equal to or higher than 9. And indeed, helping the unsatisfied user or client by making sure the problem is fastly and efficiently handled seems a very high priority for these roles, which are usually the most active in reporting bugs and technical issues in the first place.
The only thing we can do is take this factor into consideration, and use some empathy – yep, exactly the same empathy we try to use with our users! These colleagues have different goals and jobs to be done, so get ready with a bug triage process that is independent of the level of priority that they will mark. From here we move to the next learning: the (oftentimes unsatisfying) conversations between the tech team and non-tech colleagues.
4. “Yep, sure! I’ll let you know” doesn’t work
We’ve just mentioned that the product/tech team’s KPIs are quite different compared to those of colleagues working in sales and customer support. Let’s play a role game and get in our colleagues’ shoes -we have to apply that empathy we mentioned above: I’m a customer support agent and a client contacts me to report a technical issue, I bring this information to the tech team after collecting as many details as I can (although I’m sure the developer won’t be satisfied, as usual). It should go without saying that my need is to be able to check the status of my report so that I can show the client that I’ve not forgotten about them, I’ve paid attention and made sure their problems will be solved asap. Even when they contact me again the following days. It’s easy now to empathize with this colleague, isn’t it?
Then you should be surprised to hear that many of the customer care reps or account managers we talked to are not satisfied. The “Yep, sure! I’ll let you know” they receive from their tech colleagues doesn’t satisfy their simple needs. Most importantly, it doesn’t give them the chance to do their job at their best. Of course, we cannot expect the same colleague to then go the extra mile to gather all the details to make our job easier and less frustrating, am I not right?
Companies that believe in a powerful alignment between product and sales/customer care invest a bit and provide non-tech colleagues access to the product’s task management platform (e.g., Jira, Trello, or ClickUp just to name the most mentioned). In this way, as a task progresses, the colleague receives a notification and can address the angry client who’ll get in touch again the following day.
5. QA testing is not sufficient
The very last learning we want to share is about testing, and here we really collected mixed feelings. On paper, all product teams acknowledge how important it is to have a testing procedure in the pipeline before releasing changes to production. This procedure should guarantee that code is error-free, what’s known as Quality Assurance (QA) testing, but also that the user experience and the app usability are optimized, known as User Acceptance Testing (UAT). Everybody agrees this should happen.
Yet, about half of the people we interviewed confessed they don’t have dedicated resources for testing activities. In some cases it’s the product manager that carries out the task, testing the product and trying to imitate dummy user’s behaviors, such as clicking on the wrong buttons. In other cases, it’s the developers who test what they just built – and here we could (but won’t) start the huge debate on the validity of this practice (refer to this article to check popular arguments on the topic).
Nevertheless, there are several organizations where not only is QA testing done properly, but it is also automated to be very efficient and limit human errors. Nowadays many tools automatically notify you when they find code-specific errors, nothing new on this site. Yet, as many confirmed, the problem is that many bugs are not really bugs (strictly speaking, only code-specific errors are). Most of the time, the “bugs” are actually unfortunate UI/UX choices that the user perceives as technical issues. These cases represent the majority of the reports that tech teams receive, according to the product managers we interviewed, and there isn’t much we can do except bracing ourselves with patience and a desire to improve.
Adopto Bug Fix
You are probably wondering how our startup’s story ends now that we’ve finally learned to carry out a proper customer and problem discovery. After all the interviews, the individuation of the problem, of the job-to-be-done with the various pain points associated with it, we finally moved to the solution space. And here we started defining and building Adopto Bug Fix: an automated bug reporting tool that helps tech teams receive fast and detailed bug reports, without wasting time and precious resources in back-and-forth conversations with customer care and end-users.
Picture this: a user gets in touch with customer support to report a technical issue, the rep simply asks the user to press a keyboard shortcut, or click on a button on the app, and to reproduce the same steps that led to the error in the first place (this last one is a standard procedure that customer support usually carries out when receiving a report). That’s all!
Adopto Bug Fix works with a snippet of code that is pasted into the target platform’s code. It behaves like Siri: it’s quiet and invisible to the users’ eyes unless it’s activated. After the activation (with a keyboard shortcut or a click on a button), Adopto starts recording the session and collects a series of information. Among the information that it collects: there is a screen recording to check the user’s behavior on the app, the user clicks and text input, console logs, and network requests. But also specs about device and OS, screen resolution, and user ID. All these structured details are then conveyed in a report that the team can access from our platform. The report can be easily shared in any task management system. In this way, you can exploit the existing communication process you already follow to share updates with non-tech colleagues (we mentioned this at point 4).
As for today, we are in the Beta phase, meaning that we are improving the user experience and developing new functionalities thanks to the help of some product teams that have started using Adopto in their bug reporting workflows. These teams are young (not talking about age, but about product maturity), have a WepApp currently under development, receive many incomplete bug reports from end-users and colleagues, and have tried to solve the problem with a solution that didn’t bring the expected results. If you see yourselves in this description and believe Adopto could make your team’s life easier, check out our webpage and sign up to become a member of our Beta program!
Git is the most popular and commonly used open-source version control system in the modern-day. However, we barely focus on the basic concepts that are the building blocks of this system.
In this article, we will learn about the basic concepts that power your .git directory.
The .git directory
Whenever we initialize a git repository, a .git directory gets created in the project’s root. This is the place where Git stores all its information. Digging a bit deeper you can see the directory structure as below:
$ ls -C .git
COMMIT_EDITMSG MERGE_RR config hooks info objects rr-cache
HEAD ORIG_HEAD description index logs refs
The detailed structure looks like the following:
.
|-- COMMIT_EDITMSG
|-- FETCH_HEAD
|-- HEAD
|-- ORIG_HEAD
|-- branches
|-- config
|-- description
|-- hooks
| |-- applypatch-msg
| |-- commit-msg
| |-- post-commit
| |-- post-receive
| |-- post-update
| |-- pre-applypatch
| |-- pre-commit
| |-- pre-rebase
| |-- prepare-commit-msg
| `-- update
|-- index
|-- info
| `-- exclude
|-- logs
| |-- HEAD
| `-- refs
|-- objects
`-- refs
|-- heads
|-- remotes
|-- stash
`-- tags
Directories inside the .git directory
The .git directory consists of the following directories:
hooks: This directory contains scripts that are executed at certain times when working with Git, such as after a commit or before a rebase.
info: You can use this file to ignore files for this project, however, it’s not versioned like a .gitignore file would be.
logs: Contains the history of different branches. It is most commonly used with the git reflog command.
objects: Git’s internal warehouse of blobs, all indexed by SHAs. You can see them as following:
$ ls -C .git/objects
09 24 28 45 59 6a 77 80 8c 97 af c4 e7 info
11 27 43 56 69 6b 78 84 91 9c b5 e4 fa pack
These directory names are the first two letters of the SHA1 hash of the objects stored in git.
You can enquire a little further as following:
$ ls -C .git/objects/09
6b74c56bfc6b40e754fc0725b8c70b2038b91e 9fb6f9d3a104feb32fcac22354c4d0e8a182c1
These 38 character strings are the names of the files that contain objects stored in git. They are compressed and encrypted, so it’s impossible to view their contents directly.
rebase-apply:
The workbench for git rebase. It contains all the information related to the changes that have to be rebased.
refs:
The master copy of all refs that live in your repository, be they for stashes, tags, remote-tracking branches, or local branches.
You can see the existing refs in your .git directory as below:
$ ls .git/refs
heads
tags
$ ls .git/refs/heads
master
$ ls .git/refs/tags
v1
v1-beta
$ cat .git/refs/tags/v1
fa3c1411aa09441695a9e645d4371e8d749da1dc
Now, having discussed the directories inside the .git directory, let’s explore the files that reside inside the .git directory and their uses.
Files in the .git directory
COMMIT_EDITMSG:
This file contains the commit message of a commit in progress or the last commit. Any commit message provided by the user (e.g., in an editor session) will be available in this file.
If the git commit exits due to an error before generating a commit, it will be overwritten by the next invocation of git commit.
It’s there for your reference once you have made the commit and is not actually used by Git.
2. config:
This configuration file contains the settings for this repository. Project-specific configuration variables can be dumped in here including aliases.
This file is mostly used to define where the remote repository lives and some core settings, such as if your repository is bare or not.
3.description:
This description will appear when you see your repository or the list of all versioned repositories available while using Git web interfaces like gitweb or instaweb.
4. FETCH_HEAD:
FETCH_HEAD is a temporary ref that keeps track of what has recently been fetched from a remote repository.
In most circumstances, git fetch is used first, which fetches a branch from the remote; FETCH_HEAD points to the branch’s tip (it stores the SHA1 of the commit, just as branches do). After that, git merge is used to merge FETCH_HEAD into the current branch.
5. HEAD:
HEAD is a symbolic reference pointing to wherever you are in your commit history. It’s the current ref that you’re looking at.
HEAD can point to a commit, however, typically it points to a branch reference. It is attached to that branch, and when you do certain things (e.g., commit or reset), the attached branch will move along with HEAD. In most cases, it’s probably refs/heads/master. You can check it as follows:
$ cat .git/HEAD
ref: refs/heads/master
6. ORIG_HEAD:
When doing a merge, this is the SHA of the branch you’re merging into.
7. MERGE_HEAD:
When doing a merge, this is the SHA of the branch you’re merging from.
8. MERGE_MODE:
Used to communicate constraints that were originally given to git merge to git commit when merge conflicts and a separate git commit is needed to conclude it.
9. MERGE_MSG:
Enumerates conflicts that happen during your current merge.
10. index:
Git index refers to the “staging area” between the files you have on your filesystem and your commit history with meta-data such as timestamps, file names, and also SHAs of the files that are already wrapped up by Git.
The files in your working directory are hashed and stored as objects in the index when you execute git add, making them “staged changes.”
11. packed-refs:
It solves the storage and performance issues by keeping the refs in a single file. When a ref is missing from the /refs directory hierarchy, it is searched for in this file and used if it is found.
Conclusion
In this article, we covered a brief overview of the basic concepts that make up your git directory. These are the fundamental components of Git as we know it today and use on a regular basis. We’ll be learning more about these Git internal concepts in the upcoming articles.
Keep reading. In case you want to connect with me, follow the links below:
Pragati Verma is a software developer and open-source enthusiast. She has also been an active writer on various platforms and has written for many organizations as a freelance writer. As a Junior Editor at Hackernoon, Pragati helps numerous writers every day to publish their content on Hackernoon.
In her spare time, Pragati loves to read books or watch movies.
I once had the opportunity to work for a large digital company that was preparing to modernise its infrastructure by choosing a new cloud platform vendor. A small team of six developers was tasked with organising a proof-of-concept (POC) to demonstrate the feasibility of this endeavour. After six weeks of intensive work, some developers began expressing their dissatisfaction with the new platform’s cumbersome interface. Suddenly, a multimillion-dollar commitment hung in the balance, relying on the opinions of a few hands-on experts.
Over a span of three years, ending in Q1 2021, we conducted six surveys to track developers’ engagement with and adoption of various technologies. To assess engagement and adoption, we asked developers if they were working on, learning about, interested in, or uninterested in different emerging technologies. We continuously updated the list as new innovations emerged. Adoption was measured by the proportion of engaged developers actively working on a technology. To provide context, each technology was categorized based on whether its engagement and adoption rates were above or below the median, resulting in four quadrants:
1. High engagement/High adoption: These technologies captivate the imagination of numerous developers and have demonstrated commercial success.
2. High engagement/Low adoption: These technologies generate significant interest among developers but have yet to make a substantial commercial impact.
3. Low engagement/Low adoption: These fringe technologies do not attract much interest from developers, and their commercial value is yet to be proven.
4. Low engagement/High adoption: These technologies might not appeal to many developers, but for those interested, commercial adoption is high.
In our analysis, after excluding DevOps from our emerging technology tracker, robotics, mini apps (apps embedded within another app), and computer vision emerged as the most engaging technologies for developers. Approximately half of the developers expressed that they were working on, learning about, or interested in each of these technologies. While professional developers showed the highest adoption rate for mini apps, robotics piqued the interest of hobbyists and students. However, of the developers engaged with mini apps, nearly a quarter were actively working on the technology, whereas for computer vision, this figure dropped to 15%, and for robotics, it was only 10%. Despite similar levels of engagement, mini apps’ practical applications were widely recognized by developers, as adoption increased by four percentage points over the past year, representing one of the largest increases observed.
64% of developer team leads are influencing decision makers or making recommendations
Cryptocurrencies garnered the highest engagement among developers, with almost three in ten engaged developers expressing interest in learning about them. Other blockchain applications closely followed at 26%. However, the academic interest in these technologies has yet to directly translate into adoption, as only 14% and 12% of engaged developers are actively working on projects involving cryptocurrencies and other blockchain applications, respectively.
More than 40% of these developers are professionally involved in web apps/Software as a Service (SaaS), and a third are engaged in mobile development. Nevertheless, adoption increased for both cryptocurrencies (by 5 percentage points) and other blockchain applications (by 4 percentage points) in the past year, indicating ongoing exploration of practical applications. As demonstrated by companies like Maersk incorporating blockchain technology into their logistics management systems in recent years, broader adoption is inevitable.
Quantum computing and self-driving cars continue to have limited adoption rates but capture the imagination of some developers, with over two in five engaged with these technologies. However, fewer than one in ten of these engaged developers are actively working on each of these technologies. Although engagement decreased over the past year, adoption increased for both quantum computing (by 4 percentage points) and self-driving cars (by 2 percentage points). A similar pattern emerged with brain/body computer interfaces, anew technology added in the most recent survey, where many developers expressed engagement, but due to its cutting-edge nature, very few are actively working on it.
Recently, we added hearables, DNA computing/storage, and haptic feedback to our list of emerging technologies. Engagement with these technologies remains low, similar to fog/edge computing, with a quarter to a third of developers showing interest. Among the engaged developers, approximately one in ten are actively working on these nascent technologies, while two in ten are learning about them.
For each of the discussed emerging technologies, there are various barriers preventing widespread adoption. Technological hurdles are prominent, as advances required for mainstream implementation of quantum or DNA computing are still several years away. Additionally, social, cultural, and even legislative barriers can impede progress. While developers play a crucial role, they are only one piece of the puzzle.
From a common developer frustration to an award-winning company that has clients like SAP, IBM and Mentor, what does it take to turn a problem into a lucrative business? I had a chat with Greg Law who is the co-founder and CEO of undo. Greg went from founding his company in a shed to building a business with top enterprise customers. What we all want to know is – how? Read on and get inspired! Could you be the next Greg Law / Undo?
Vanessa:Tell us a bit about Undo.
Greg: Undo is a tool that allows developers to see what their software did and why, at any point in time. The tool (LiveRecorder) allows engineers to record the execution of a program and wind it back to see exactly what it did to identify software defects. You can step line by line in a debugger – forwards or backwards – and see all of the program state too.
Customers use us when they are completely stuck with an issue, and rather than guess what the problem is, they can pinpoint it. There were devs who would spend days, even months trying to figure out the source of a bug, and they try LiveRecorder and it enables them to figure it out in a few minutes.
The tool was originally aimed at the enterprise market, but more recently it has been used by more smaller companies, even those with small teams.
“The pandemic helped change this, there was no more travelling to meet with potential enterprise customers, and thankfully the tool was matured enough that it could be downloaded by people from our website, without the need to support hundreds of support requests.”
It was always part of the grand plan but the pandemic brought it forward.
Vanessa: How did you build your team?
Greg: It’s kind of the classic story. I founded Undo with a good friend of mine, Julian from when we worked at Acorn back in the day. We worked evenings and weekends together, it reminds me of a quote I heard recently, a programmers mantra of “We do these things, not that they are easy, but because we thought they were going to be easy”. We did eventually get to a v1, then bumped into an old friend that Julian and I had worked with at Acorn, he was looking for his next job. He joined us in the shed at the end of my garden, that was in 2013, and he hasbeen with us ever since.
Vanessa: How many are devs on the team?
We have 34 on the team.
Vanessa: Which collaboration tools do your team use to stay on top of the projects?
Greg: Git with GitHub on top of that, in fact in the early days it was just Git.
We used a todo.txt file and when we had 3 or 4 people that worked really well. It’s quite nice that you mark things in different states in different branches and it all just works. But obviously, it doesn’t scale. We used Phabricator for a while but ended up switching to GitHub.
Google Meet – and all of Google’s G-suite. There were worries about locking into a giant corporation but the convenience of it is too great!
Collaboration is about culture more than tools. We were definitely an “in the office culture” prior to the pandemic, and felt that the facetime, building deep relations and trust were good face to face, and that worked really well. That said, we were already beginning to recruit remotely in some exceptional cases. And of course, that has now changed 18 months ago and we transitioned like everyone else due to the pandemic.
If the pandemic happened ten, even five years earlier, it would have been alot worse for those in the knowledge industry. Even five years ago video conferencing was expensive so having Google Meet made things a lot easier. The most important thing with remote working is to write stuff down so that you can communicate asynchronously, not just remotely. Google Docs has been very good for that.
Vanessa: What kind of culture do you offer to developers in your company?
Greg: It’s one of those things that is quite hard to define. I cringe so often when I hear people’s answers to this question. It can be cheesy, and buzzwords. Often if a company publishes it’s values, they are actually aspirational values, kind of what they want to be better at, not what they are doing right now. So one of our values is no bullshit. Be honest with each other and ourselves.
That is a key component in building trust, and that’s the biggest one for me. There are the easy kinds of trust, like, do I trust that I can leave my wallet on the desk and it will be there when I get back? Then there are more difficult levels of trust such as:
1) Do I trust your intentions? Do I trust that we are trying to achieve the same thing?
2) Do I trust your judgment?
3) Hardest of all – healthy conflict.
I can say to you: “I feel let down, you didn’t do what you said you were going to do or you didn’t do a good job with that.” I can trust you enough that I can say that, and it’s going to be ok between us. It’s much easier said than done, and though we are fairly multi-cultural sometimes we can be a little bit too English about everything! So we need to be un-English about it, and say what we feel, obviously in a respectable, polite way, to have that trust and transparency.
And that was actually part of why we were quite big in the early days of building the company, not remote first, but having us all together. Not that you can’t build high integrity and high trust remotely, you can, but it is harder.
We were already becoming a remote culture and had a remote office in San Francisco, and we hired people from across the country, like in London. The first few people you hire will define your culture. As a founder, you have a lot less influence than you thought, culture is a self-defining thing. With picking the right early hires, we just got really lucky, we had no idea what we were doing. Now we’re in this new world and we hire much more freely regardless of location, and we have the core culture that we can build it on, it actually works really well.
Getting to know you
Vanessa: Have you always wanted to be a developer?
Greg: I wanted to be a train driver! Once I got over that, I got a home computer at the age of ten, my mum sacrificed to get the computer. At first I was just playing games on it (Commodore Plus 4) and she strongly encouraged me to learn and program with it, so I picked up a book to learn, out of guilt really, and from then on I was hooked, all I wanted to do was program.
Vanessa: Did you go to college and beyond or are you self-taught?
Greg: I took Computer Science at degree and also at A level not many six forms offered that at the time. I realised that it paid well to do something I’m good at. The world developer population is not growing that fast, which is surprising, We need to train more programmers, but we’re always going to have a big undersupply so we need to make that finite pool of programmers as productive as possible.
We need a healthy ecosystem to help people be more productive. Ten years ago, software tools were a brave business to be in. Now it’s one of the hottest places for VC’s to invest in.
Vanessa: Have you ever been involved in mentorship, either as a mentor or a mentoree?
Greg: We’re all still learning every day, I have mentored. In fact many of our employees are a mentor to me. We’re lucky that there is a healthy ecosystem in Cambridge. It’s amazing really – you can email almost anyone you can think of, even when you’re right at the beginning and they’ll spend a bunch of time with you.
The Future
Greg: Core tooling, slowly they have evolved compilers, IDE’s. Debuggers have not changed much over the years, new tools have come along but the fundamentals have not changed much over the decade
We see waves of tech. There are rapid periods of changes, computer operators were like train operators – if you used a computer for work that’s all you did, and no-one else would be let near them. Then in the 80’s people started using computers as part of their other job, now everyone is using them, and now there are smartphones. As these waves went by, the way we developed changed too – i.e. it goes in waves. Between say 1990 and 2010 the way we develop code was all evolution not revolution. Then suddenly it all changed again, first with agile, then CI/CD, huge amounts of reuse of open source, etc. With these big changes comes an explosion of tooling. It’s really hard to imagine what will continue. I think most of the tools we use today will still be in use in ten years, but they will have been added to. Like how GitHub compliments git, or our stuff does with Jenkins. I’m sceptical on the AI writing code thing – understanding of requirements through context and delivering creative solutions to that – it’s a million miles away from the state of the art. But I do totally see computers helping us to write code – the GitHub Copilot stuff promises to save a bunch of time. But it’s not quite as exciting as it looks because if you think about it, Copilot saves you time typing in the code sure, but what proportion of programming time is actually spent typing the code in? Pretty small. A much larger chunk of time is spent figuring out why that code you typed in this morning doesn’t do what you thought it was going to do! That’s why we started Undo, and I think we’re going to see a lot more around this notion of understanding or auditing exactly what happened.
Collaboration will be key. Asynchronous collaboration. Once you sever the link, you no longer require people to be geographically in the same place, well then you no longer need to be in the same time, either. This has potentially profound implications for how we might work. We have used version control in development for decades which allows people to collaborate remotely and asynchronously; I think these practices have a lot to teach a wider audience in asynchronous collaboration. In kind of the same way that the first word processing applications were actually code editors.
We’re good at writing code, but not at debugging, most devs spend alot of time debugging – remote and asynchronous collaboration through debugging would be great.
Vanessa: It was great to talk to you Greg!
We love to hear your development stories, get in touch to share yours.
Our referral program counts over 2,800 developers who are quick, smart, and masterfully spreading the survey with their local developer groups and communities. We know that all of you are very keen on winning the top referral prizes like $ 200, $700 or $1,000 USD. But only the top 50 will score rewards. So we recently spoke with one of our top 3 referrers from the previous survey, and he was cool enough to share a few tips on how to climb the leaderboard faster. Read, learn, and apply!
1. Spread your influence. Twitter is cool but in some countries Whatsapp, Telegram, and Discord developer groups are more eager to back you up and take the survey to support you. Test a mix of different apps and sites.
2. Be intentional. It’s ok if you share the survey occasionally to boost your ranking. But if you want to get to the top, it’s worth planning ahead. Try to be active on specific days or times when you know other developers will be scrolling through their phones.
3. Learn about the people before posting. If you’re posting in a new developer group, forum, or Slack channel, it’s worth getting to know the vibe of the group first. Some are more casual, some are all about learning, some love memes. When you share the survey with them, try to blend in as a native.
4. Some people love to hear about the survey prizes, some don’t. That’s ok. You can focus on saying that the survey is actually a good learning opportunity to discover new tools and platforms.
5.Use the promo material we have prepared for you. Feeling a bit confused about how to promote the survey? Don’t know what to say? Pick a few tweets, banners or promo texts & grab your custom promo link to share with other developers.
6.Remind people that they need tocomplete the survey, so as to count towards your referrals. Perhaps some have started the survey and paused. Give them a gentle reminder to go back and finish answering the questions.
7. Mention that thesurvey is closing on August 4th. It helps when people know that there’s a deadline and they need to act fast.
8.We’re donating $0.10 for every response to a charity that developers can select when they enter the survey. That’s a nice way to motivate people to support you and our survey too!
Hope these quick tips will inspire you and keep you in the game so that you can climb the leaderboard and win our top 50 prizes. Just remember to play fair and square and only promote the survey to real developers and software creators (sorry, you can’t ask your mom or cousin to click randomly!). Read our Referral Terms & conditions to make sure you’re playing by the rules. Good luck!
