DEV Community: Eszter Szücs-Mátyás

Making a clone of your WSL environment (and using it in parallel)

Eszter Szücs-Mátyás — Fri, 15 Sep 2023 13:25:00 +0000

1. List installed distributions

wsl --list

2. Export Linux Distro to clone

Pick the distribution you want to clone and add use the name in the following command. It will take a snapshot of the distribution to a selected location.

Pro Tipp: You can also use this command to back up your WSL state so you can restore later, or use it on an other Windows instance.

wsl --export <DistributionName> <FileName>

Example:
wsl --export Ubuntu ubuntu.tar.gz

3. Import snapshot as WSL image

In this step, you will install the archive file as a WSL distribution package on the computer, as it would be an app. The InstallationLocation is not optional, you can select any folder freely. The the default location when downloading a distribution image from the app store is _C:\Users<WindowsUserName>\AppData\Local\Packages_, so I tend to select that folder for this purpose as well.
The DistributionName should be different from the original distribution name. In my case I suffixed it with a 2, you might want to choose something more descriptive.
FileName is the exporter archive from the previous step.
wsl --import <InstallationLocation> <DistributionName> <FileName>

Example:
wsl --import C:\Users\dangernoodle\AppData\Local\Packages\Ubuntu-LTS ubuntu-2 rootfs.tar.gz

4. Install and Start distribution

wsl -d <DistributionName>

Example:
wsl -d ubuntu-2

5. Done!

DevEx 101: Looks Good To Me

Eszter Szücs-Mátyás — Thu, 08 Jun 2023 12:53:45 +0000

When and where I started my career we had no automated code checks. When I opened a change request to our code, I had to ask two of my colleagues to review the change and it usually came back with a list of typos to fix, functions in need to break up, formatting problems, requests for explanation and the final boss of comments let's talk about this.

Time passed by, the number of comments went down and usually I only got a single message saying 'LGTM'.

I could say I was a perfect programmer and learned one or two things about spelling words right, but what really happened was my colleagues letting their guards down on smaller mistakes. It's trust. It's beautiful. And it made me a couple of long shifts fixing uncaught bugs.

Now I think we do code reviews for all the bad reasons.

All The Bad Reasons

The PR has to have at least X approvers

Oh those company guidelines! We ask for review because we have to ask for review so we end up with a rubber stamp and not learning anything. Usually the approver doesn't even know that part of the software very well, or is too busy to be bothered.

- Recommend Reviewers: Create groups of people familiar with certain services or parts pf code. Don't assign everyone of every part of the code, unless it's common domain.
- Time to Review: Create tags with estimation on how much time it takes to review the PR. I bet PRs with 5-15 minutes review time won't get stale as 45min monsters do.
- Similar PRs: If you have to update configuration in multiple repos, group the changes!.

I'm not sure this will work

Could be lack of confidence in self or in the system, anyways, you need to talk about the testing strategy.

- Start with tests covering the existing features that might break.
- Test on an ephemeral environment.

Does this fit the code aesthetic

Code aesthetics, typos, grammar or formatting should not be part of the reviewers job but it often still is.

- We are lucky we can implement automated PR checks to run linter, grammar scanner or anything we agree on before even asking a human for feedback. For this, you need to hold the addition of reviewers until all automated checks ran.

All The Good Reasons

I want to talk about my solution

The code feels incomplete or could probably be improved

I have concerns about nearby code

I rebased my branch and I want to know if something relevant changed

Anything can be a good reason until it starts an interesting conversation or pushes us towards smarter solutions. Just don't forget to spend your time with meaningful reviews and automate the boring stuff.

DevEx 101: psychological safety and test automation

Eszter Szücs-Mátyás — Sun, 14 May 2023 13:35:01 +0000

You love roller coasters, right? If you are sure it's well maintained. You love climbing? If the ropes are in place.

Psychological safety is the state of mind where you are not afraid to take chances, make mistakes, and get messy. Because while doing so, you feel safe.

Safety at the workplace opens people up to collaboration, innovation and increases employee retention rates. Why? Same as roller coasters, boulders and spaceship codes, danger is fun until it is, well... not actually dangerous. Let's see what can testing do to help cushioning workdays.

Reputation

In my experience as a DevOps engineer, this hits hard with developers on every project, every culture. I have seen companies measuring test coverage of lines of code, characters even and that did exactly the opposite of what the management expected. The number of errors did not go down, test breaks slowed down development and automation pipelines. Until we changed the KPIs. We started to measure code coverage by how many bugs a feature produced.

Except some bugs which can't be bound to a parent, bug numbers went down at an instant. Now, instead of polishing statistics, devs were putting meaning behind testing. Started asking questions to cover more possible testcases. Introduced new testing strategies to spot the bugs as early as possible. Luckily the management allowed time for meaningful discovery. And they never went back on this decision, because cumbersome and expensive manual testing went down drastically.

Taking calculated risks

What if? We all have those great ideas we would try if we would be sure it works out. Wouldn't be nice? When tests are covering the core functionality of the software, it makes it easier to test wild ideas and unusual solutions. When the outcome can be assessed easily, you will move faster and easier. Can we migrate the entire codebase to WebAssembly? No if we have to reverse engineer all details of the logic before even starting. Can we do so by satisfying the existing tests? Of course, we have the requirements in place, a way to measure progress, validating the results, what else do we need?

Make blameless culture happen

When I get a new colleague, and all training settle, I never miss to explain the post mortem, crisis meetings, how to initiate critical patches and other procedures in case of risk. Because I don't want anyone to keep their ideas in the drawer because they don't trust testing. It's interesting how software testing is around since the nineteen-fifties and still sounds like space age for some. This is the least I can do to let them know, we can stay in control when something goes in unexpected directions.

We don't need guided meditation to learn to manage stress. We don't need time management training to find time to write unit tests.

What we need to feel safe

Chaos days to practice handling stress by unexpected issues
Open communication between developer, QA engineer, tester and product personnel about the goal and use of the features instead of outlines of function
Measuring tests by results (nr. of bugs in production) instead of line coverage
Providing time to developers to write tests, instead of driving the code forward and make manual testers more work

DevEx 101: Happy Onboarding!

Eszter Szücs-Mátyás — Wed, 03 May 2023 15:11:19 +0000

When done right, effective onboarding can help new developers feel welcomed and valued, which leads to higher job satisfaction and retention rates. Having a clear plan helps new developers understand what to expect, reduces uncertainty, and ensures that everyone is on the same page. Here are 5 things that can make these days a breeze!

Pop-up developer environment

Wouldn't be nice to have everything up and running in a matter of a click? Although we are not there yet, there are many tools to create self-contained developer environments. Let me show you 3 solution, all of which provide benefit from very low effort investment.

Tilt

If you are developing to Kubernetes, you will love Tilt!
Tilt is a development environment tool (Who saw that coming, huh?) that spins up your microservices in a matter of a CLI command. After that, no more CLI, no more kubectl, just happy developing.

The tool utilizes a configuration file that can automate any workflow necessary to get your local environment running. Except building, caching and starting up all containers, because that is built in. You will develop in the containers, the home of the code in production, so all precaution is done to prevent drifts or unexpected errors. What about hot-reload? You might ask. Tilt knows that seeing the result of code changes immediately is non-negotiable, so all changes is code, configuration or even the Dockerfiles are listened to and trigger a rebuild. Don't worry, it only rebuilds the components affected by the change.

Currently Tilt runs everything on your local machine, that is huge a benefit for some, especially the security and budget savvy. They are working on a cloud offering, that will allow further collaboration and ease for developer teams.

Microsoft DevBox

A new sweetheart of enterprise and dotnet developers is Microsoft DevBox. It spins you up a virtual machine in the cloud based on pre-configured SKUs with all that you need to start working on projects immediately.

This is yet in public beta, you can have a machine re-installed with a suite of development tools, including Visual Studio, .NET Framework, and Azure SDK. You can customize it by associating repositories, configuration and container images with your account, although it lacks the ease of configuration yet.

What makes the most appeal to enterprise teams is the lack of network whitelisting and ticket hunting. It uses reverse proxy, no special port so it won’t crash into policies. For the most popular development stacks, you can already find pre-built virtual machine images on Azure marketplace.

GitHub Codespaces

Probably one of the best known options for virtual developer environment is Codespaces. The tools and configuration are defined in a configuration file in the familiar format of json and Dockerfile that can be (I think, should be) stored in the same repository as the source code.

The installation of frameworks and tools, even checkout of the sourcecode and installation of dependencies are done by the time you log in to start working. The work environment is actually remote, a container in a virtual machine in the cloud. You can still use your code editor of choice to connect, with solid internet connection your experience won't be any different from working on your own machine.

A huge pro is that the container specs can be adjusted to have the best value and performance to the given feature. Need to run multiple services on the same host? Scale up! Fixing up CSS of a small website? Scale down!

Simple source control strategy

Keep it simple stupid, right? It sounds easy until everyone agrees what simple is. When you are accustomed to complicated a system, it starts to feel simple.

Simplicity is consistency. Choose a branching strategy from the public domain and stick with it whenever possible. Developers will greatly appreciate that they can continue working with a familiar workflow.

Keep repositories independent. No modern tools have utilities for submodules, resulting in outdated dependencies, skipping tests for code blindspots and you need to document what submodules are required for what features. If working with legacy code, consider developing custom automation for dependency documentation and management.

Predictability is the most important aspect of simplicity. If merging to main on one repo automatically triggers CI/CD but on the other repo it's a manual process, you may cause someone a heart attack. Talk

Understand the task

Choosing the right first tasks is pretty important. You want the very first task to be trivial. Something that can be done in 10 minutes, or even less. It can be made up.

If you ever participated in Hacktoberfest, you must be familiar with this concept. The point of the first task is to get familiar with the codeflow, the review process, the environment and give a little burst of accomplishments into the long first days.

This practice is pretty widespread among the industry but after newhires tend to fall into the grey workdays. I have a meeting format to talk through features with the newbies. I have the curse of knowledge and they don't know what they don't know, so a little help to cover the most important topics doesn't hurt. I stole the format from design thinking. Feel free to adjust the questions to your situation.

Discover

Did someone work on this task already?
Who is a user/tester who can help me understand the success criteria?

Define

What does it look like when it works as expected?
What does it look like when it does not work?
What dependencies does this task have?

Ideate

Can I break down this task to subtasks?
Which tool do I have to accomplish this task?
What features of the techstack can I use to have the best result?

Prototype

Point to code that can be reused
Write pseudo-code together to conceptualize the solution

Test

Show how the feature can be tested
Talk through test data
What access, permission, account etc. is needed for testing

Get help (even if you don't need it)

Are you doing mob programming? You should! Building a team is facilitating communication and embracing connections. The best way to figure out the team is to work together. This is the concentrated version.

Schedule a half day with the team to work on the same issue together, with a single laptop (or screen for remote teams).

It is a great tool to learn from and about the team, tackle a real problem, build mutual trust and find the vibe. It can be a bit intense, but makes it easier and more likely for the newhire to ask for help.

Deliver

Think about what creates attachment in people! When you see your feature grow up... I mean go to production. One of the reasons why CI/CD is so popular is that developers are more likely to take ownership over features if they triggered deployment to production. That is not possible everywhere, but facilitating the experience to allow a newhire follow their feature from start to finish is.

Not only will it hep with engagement, it also helps understanding the software delivery lifecycle from the definition of the feature to the deployment. Cross-team communication is stellar for engagement, understanding constraints, practices and growing empathy along the way.

Here is a song to mumble while thinking through the essential contacts to have on the list

DevEx 101: What is DevEx?

Eszter Szücs-Mátyás — Tue, 02 May 2023 11:40:39 +0000

What have you done today to increase your productivity? What did your team manager, department heads or organization do today to increase your productivity? Welcome to developer experience, where we explore engineering practices that increases your work life.

What is DevEx about?

If you feel like your company does not take action in bettering developer experience because they don't see the profit, this might just the thing for you!

DevEx, DX or Developer Experience is a set of practice that focuses on providing the support, usability and documentation that developers deserve. In exchange employers see results in increased deployment frequency, decreased lead time for changes, recovery time and change failure rate and better employee retention rate. Sounds like a fairy tale! Investing in removing friction from day-to-day work is not a new idea however making it measurable is a lot easier with the tools popping up on the market.

Improving on-boarding speed and experience

Everyone loves onboarding! You are a fresh new employee, with a checklist that guides through from setting up your developer environment to getting your first feature released. You will have your first commit in prod in your first week. It makes you feel good, not pressured, because the expectations are clear and leave you plenty of time to network with your colleagues and do the important compliance training. (No, I don't know how to make compliance fun.)

If this isn't your experience, you should stick around to read the upcoming articles about

How to build and on-boarding checklist?
How to build self-documenting software delivery life cycle?
Pop-up dev environment with Microsoft DevBox

Making Information accessible

Just look at the documentation, it's on Confluence!

Famous last words before pointing at a documentation that is either outdated or assumes knowledge only that one developer has who has no time to explain it. Familiar? Everyone knows that easily accessible information can take productivity to the next level. We also know that writing documentation and doing knowledge transfer sessions are time consuming, low priority and difficult.

Let me help you by some free templates and tutorials on

How to build and document your software delivery life cycle using markdown?
Get better with Swagger!
Design Decision Documents made simple
Software Documentation Formulas to steal from the Opensource Community

Getting Feedback As Soon As Possible

I will be honest here. I hate to receive PR comments on a typo. I hate when the CD pipeline fails on the tests because I forgot to comment back a block of code. I am in rage when the linter fails because I did not run it on my local machine. I am the only one to blame here... or am I?

Do you know how to set Pull Request gates to run tests before the code is merged?
Do you have pre-push hooks to check your code before making it to the codebase? Is it annoyingly slow?
Are the test failure notifications going to spam? Or just sit there abandoned in the developers mailbox?

Yes, we will cover that!

Preventing Burnout

I bet you don't think about how Google works when you search for something. It just does.

People underestimate how much the tools we use contribute to our stress levels. Usually it's not even the fault of the tool really, it's just simply matter of configuration. We will look into lesser-known features of developer tools that saves you 10 minutes that's just enough for a good water cooler chat.

We will look into building career road-maps to help developers find their next goal.
Facilitating mob-coding to make everyday work feel like a hackathon? Will do!

If you reached this far, I hope a couple of topics grabbed your attention and will return for the articles and tutorials posted bi-weekly.

Let's make work a better place together!