Category: Tips

Categories
Tips

How to Upskill Your Cloud, SRE, and DevOps Experts to Empower Your Organisation

How to Upskill Your Cloud

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.

Categories
Tips

When the problem is: incomplete bug ?reports

Bug reporting

Fall in love with the problem.

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. 

Source: https://www.cblohm.com/blog/education-marketing-trends/adoption-curve-education-marketing-strategy/

3. Priority is not mathematics

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.

Work chronicles

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!

Sign up for free for our Beta program

Categories
Tips

Git Internals Part 1- List of basic Concepts That Power your .git Directory

How does Git store your data

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

  1. 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. 

$ cat .git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[user]
    name = Pragati Verma
    email = pragati.verma@gmail.com

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:

LinkedIn | GitHub | Twitter | Dev

Bio 

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.

Categories
Tips

Developers influence technology decisions 

Developers influence technology decisions

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

Developers influence technology decisions

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.

Categories
Interviews Tips

How to build a debugging tool and turn it into a business

How to build a debugging tool and turn it into a business

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.

Categories
Tips

7 Tips on How to Win In Our Referral Program

7 Tips to win our Referral Program

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 to complete 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 the survey 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!

Categories
Tips

10 books on computer vision and cryptocurrency you should read

computer vision and cryptocurrency books

In our latest Developer Nation Pulse report we shared data on the top five emerging areas of interest to developers.

Around half of developers say they are working on, learning about, or interested computer vision, according to the insights from our Q1 2021 global survey of over 17,000 developers. Similarly, 45% are interested in cryptocurrencies (e.g. Bitcoin).

Recommended computer vision and cryptocurrency books

However, of the developers engaged with computer vision, only 15% are currently working on the technology. Similarly, only 14% are currently working on cryptocurrencies. One in four developers are currently learning about computer vision, while 29% are learning about cryptocurrencies.

So if you belong to these group, the following book recommendations might be just the thing you’ve been looking. This post was created in partnership with our friends at Packt.

Computer Vision books

Modern Computer Vision with PyTorch

Explore deep learning concepts and implement over 50 real-world image applications.

What reviews say:

“I felt the book is very well structured and compiled. Unless you’re looking for something very very specific, you’d be able to find techniques/implementations for any and all types of problems you are working on. They cover algorithms and implementations of basic neural networks, all the way upto RNNs and reinforcement learning with PyTorch. The breadth covered by this book on the number of techniques and algorithms is really amazing.”

Mastering Computer Vision with TensorFlow 2.x

Build advanced computer vision applications using machine learning and deep learning techniques

What reviews say:

“There are many books out there / but this book stands out – very clear explanation of codes and contents, lots of detailed explanations for object detection, classification, visual search, matching and training in cloud.”

PyTorch Computer Vision Cookbook

Over 70 recipes to master the art of computer vision with deep learning and PyTorch 1.x

“This book is good for beginners to learn about writing deep learning model in PyTorch. Book goes from basic linear model to processing videos in PyTorch and covers variety of use cases e.g. use of GANs, Style transfer project.”

Applied Deep Learning and Computer Vision for Self-Driving Cars

Build autonomous vehicles using deep neural networks and behavior-cloning techniques

What reviews say:

“This book is about how to apply deep learning knowledge to solve self-driving car problems. The technologies mainly focus on computer vision areas. It gives readers lots of code samples, which can help readers to understand the concept in each chapter.”

TensorFlow 2.0 Computer Vision Cookbook

Implement machine learning solutions to overcome various computer vision challenges

What reviews say:

“By far, this is one of the best books to understand how to apply deep learning in the field of computer vision. The concepts have been clearly explained. It covers almost everything from image classification, image segmentation, object detection, etc”

Raspberry Pi Computer Vision Programming, Second Edition

Design and implement computer vision applications with Raspberry Pi, OpenCV, and Python 3

What reviews say:

“This book was very helpful for me because it covers a wide variety of computer vision topics and offers lots of well thought out code examples using Python, opencv, matplotlib, numpy and other computer vision software. I followed his examples on my RPi and found that they helped me get the format and arguments of opencv commands correctly to include little things like commas, parenthesis, brackets, optional arguments and the like.”

Hands-On Image Generation with TensorFlow

A practical guide to generating images and videos using deep learning

What reviews say:

“The book is a great quickstart into representation with neural networks. (I also read it more deeply at times and it is great for that as well. I myself have experience with high-throughput large scale autoencoders with TensorFlow and building Facial Recognition applications. I appreciated this book a lot.)”

Cryptocurrencies books for developers

Practical Artificial Intelligence and Blockchain

A guide to converging blockchain and AI to build smart applications for new economies

What reviews say:

“Addressing such large topics as artificial intelligence and blockchain at best is a very serious endeavor. Whereas blockchain after a decade plus of existence has developed a useful understanding within its marketplace, that is not at all true of artificial intelligence, better just AI. AI is now well beyond 6 decades of existence as a topic and yet remains in an evolving state with much debate and speculation worldwide, especially over ethical and scope issues. So given that the reader of this book may be either one-of or some combination of a professional scientist, a developer or simply someone wanting to learn, then yes, Ganesh Prasad Kumble’s Practical Artificial Intelligence and Blockchain book is both a good and useful read.”

Blockchain Development for Finance Projects

Building next-generation financial applications using Ethereum, Hyperledger Fabric, and Stellar

What reviews say:

“This book is for developers who want to learn blocking technology by building financial applications. Kudos to the author on providing coding examples and following it with explanation. Overall it is a good book on Ethereum development and I would recommend it for anyone who wants to learn Ethereum blockchain by building fintech applications.”

Securing Blockchain Networks like Ethereum and Hyperledger Fabric

Learn advanced security configurations and design principles to safeguard Blockchain networks

What reviews say:

“This book is for blockchain developers, security professionals, and Ethereum and Hyperledger developers who are looking to implement security in blockchain platforms and ensure secure data management using an example-driven approach. Basic knowledge of blockchain concepts will be beneficial.”

Is there a book or expert that you would recommend to others interested in cryptocurrency or computer vision? Do share in the comments.

Our latest developer survey is live. Let us know which emerging technology you’ll be exploring in 2021.

Categories
Tips

Hello, world. Meet Developer Nation!

developer nation community, developer nation survey

It’s a new era for our community, Developer Economics is now Developer Nation.

Over the last ten years we’ve gathered over 40,000 developers with one thing in common: an unyielding curiosity about what the future holds for software builders. Together with all of you we’ve run 20 global developer surveys, co-created over 300 blog posts, read over 20 reports, pondered over 300 graphs and tried to make sense of the emerging trends in the developer world and what they mean for you and your projects.

Now it’s time to reveal a new chapter. We want to be more than just a survey, a report or a newsletter you interact with from time to time. It’s time to shift the focus from us to you – a diverse group of curious and ambitions software creators who want more from the ecosystem: more support from the platforms, more value for your time, and more chances to learn from each other.

Why Developer Nation?

For the last 10 years we were known as Developer Economics. It helped us earned the trust of tens of thousands of developers over the years. But it’s not helping us resonate with many, many more software creators out there. The “Economics” part especially. We have evolved beyond analysing revenue models for developers. We’ve grown by mapping trends across a wider ecosystem of developer tools, platforms, technologies, and programs. The future is about helping all software creators (developers and no-coders alike) influence how the software is built.

We approached the new name from different angles: blending concepts, metaphors, acronyms, dev jargon, pop culture, creative spelling, crunchy suffixes, Latin words, fringe Greek gods, and more. We came up with 157 name ideas! We then asked around 1,000 of our most loyal members for a feedback. Developer Nation is the name that stood out the most with you. It was associated with trust and excitement.

With a new name comes a new responsibility

Our vision is a software development ecosystem that listens, empowers, and supports software creators to pursue continuous learning, build future-forward solutions without compromises. We want to help you feel confident in your technology choices and included in the conversation about the future of the ecosystem.

We pledge to do this through a global research, sharing with you trustworthy data about emerging software trends, and offering you new opportunities to connect with the people at the service of software builders.

How can you get more involved?

We’ll be testing new programs and channels through which you can connect with other software creators and platform leaders to exchange ideas and experiences.

We want to give you more space and opportunities to speak about the topics that you find relevant and other software builders will care about:

  • What’s in your toolbox?
  • What was your journey to becoming a software creator like? Your biggest mistakes and “a-ha!” moments?
  • Which software development trends need to be questioned and which deserve more attention, in your expert opinion?
  • Which books / podcasts / events / blogs / people inspire you?
  • What projects are you working on and how can our community help you test, give feedback, and earn users or followers?

Find out how you can get involved here.

We’ll still invite you to participate in our global surveys twice a year.

We’d also love for you to read our blog, reports, and newsletter.

It’s a feature, not a bug

Some of our links and form still refer to developereconomics.com and your user profile is still a bit of work-in-progress. Hang in there, we’ll get it sorted!

Say hello to our team!

Last but not least, it’s about time you met the people behind the screens who want to turn this into a real community!

Categories
Tips

7 DevOps books to read in 2021

7 DevOps books to read in 2021

If you are looking to learn more about Ansible, Azure, Docker, Terraform, Kubernetes, and their roles in DevOps, then this blog post is for you. We continue our series of must-read books with 7 DevOps books to read in 2021, as recommended by our friends at Packt.

Azure DevOps Explained

Get started with Azure DevOps and develop your DevOps practices

What reviews say:

” In my opinion, it is definitely one of the greatest books I ever read for DevOps.
Although I am Azure DevOps certified, I really enjoy reading this book and it gives me an extra overview of what I have learned.
It is well structured and the fact that is simple to read and follow along makes it more attractive. “

Terraform Cookbook

Efficiently define, launch, and manage Infrastructure as Code across various cloud platforms

What reviews say:

” I had the chance to read this book and I was really pleased by its content.
noting that this is not the first book or terraform material that I read, I would say that this book contains valuable structured information with also access to code used in various chapters.
it is certainly an asset for those starting their journey with terraform.”

Practical Ansible 2

Automate infrastructure, manage configuration, and deploy applications with Ansible 2.9

What reviews say:

“This book is probably perfect for someone with reasonable experience. It was what I needed as a second book to get a good look at the ecosystem and a second opinion of how to use it. “

Kubernetes – A Complete DevOps Cookbook

Build and manage your applications, orchestrate containers, and deploy cloud-native services

What reviews say:

” Great coverage of common Kubernetes and DevOps tools. I’ve learned about some of the tools I haven’t used before like Jenkins X, GitLab, Fossa, Trivy, Litmus Chaos etc.
Although some of the long YAML files are provided in the GitHub repository I got the digital version, makes it easier to copy paste. “

Kubernetes and Docker – An Enterprise Guide

Effectively containerize applications, integrate enterprise systems, and scale applications in your enterprise

What reviews say:

“If you have worked on Kubernetes at all, you have experienced the frustration of trying to go beyond a cluster that has a single config file and a simple layer 7 load-balancer using NGINX. This book does truly target not only the enterprise user, but any person that wants to learn topics that make Kubernetes a complete offering.

I have been looking into the external-dns project on my list for a few months, but I never got around to doing much – Much to my surprise, when I was reading the topics covered in the book, it mentioned Services and external-dns. Chapter 6, alone, to me is one reason to buy the book since it explained and showed me how to install Metallb with external-dns in easy to understand terms and hands-on configuration.”

Learning DevOps

The complete guide to accelerate collaboration with Jenkins, Kubernetes, Terraform and Azure DevOps

” I would suggest reading through each section before you work along with the steps. There’s lots of references to other resources that are not necessarily part of the topics being discussed ”

Docker for Developers

Develop and run your application with Docker containers using DevOps tools for continuous delivery

” When reading articles, tutorials and even books, that is very common that at the end of the reading you struggle about how to translate that to a real production situation. Believe me, this book is different. You get to the end with a sense that you are very likely to know what are the next steps to apply what you learned to your existent or new projects. And this means a lot. The book has some great balance from history, concepts, example and practice. ”

What books have helped you deepen your knowledge of DevOps? Do share in the comments. Looking for more books to read? We have also shared recommended Backend and Frontend books.

Categories
Tips

Five backend books you should read in 2021.

Powering up your backend knowledge? Our friends at Packt have shared five backend books you should read in 2021.

Powering up your backend knowledge? Our friends at Packt have shared five backend books you should read in 2021.

Node Cookbook, Fourth Edition

Discover solutions, techniques, and best practices for server-side web development with Node.js 14

What reviews say:

“Want to learn Node.js, brush up on your skills, or discover the latest features of Node 14 and beyond? This book is for you! Written by a senior developer and Red Hatter, With a thorough presentation of everything Node, Bethany Griggs delivers from cover to cover in this latest Node Cookbook edition.“

Node.js Web Development, Fifth Edition

Server-side web development made easy with Node 14 using practical examples

What reviews say:

“This book is great. I had some knowledge about full-stack JavaScript, but this book has already taught me a lot. I wouldn’t say that this book is for a complete beginner to software development (coding), but it’s definitely good if you need to deepen your understanding of JavaScript, or if you’re interested in getting started with JavaScript from another backend language like Python, C#, Ruby, etc.”

ASP.NET Core 5 and React

Full-stack web development using .NET 5, React 17, and TypeScript 4

What reviews say:

“The book had a very methodical approach to building single-page applications through React. I am familiar with React and .NET separately and partly why I could pick up the concepts in the book faster but I believe otherwise too, things are laid out very clearly. Recommend it for beginners.”

Full-Stack React, TypeScript, and Node

Build cloud-ready web applications using React 17 with Hooks and GraphQL

What reviews say:

“Nook has a philosophy of “learning by doing” “

Building Vue.js Applications with GraphQL

Develop a complete full-stack chat app from scratch using Vue.js, Quasar Framework, and AWS Amplify

What reviews say:

“This book is a fantastic deep dive into building an end-to-end application on AWS. I really like the fact that he dove deep into many topic areas, showing how to tie everything together to build something that is a real-world use case. The information in this book can also be used in many other areas so the knowledge is very transferable to other scenarios and use cases.”

What titles do you recommend? Share your thoughts in the comments.  Looking for more inspiration? Here are more book recommendations.