DEV Community: Anže Pečar

Mastodon Instances with Software Developers

Anže Pečar — Wed, 17 May 2023 22:11:04 +0000

If you are a software engineer or someone learning or interested in software development you might want to create an account on an instance with other software developers so that your local timeline is full of relevant content.

For Fedidevs I have indexed some of the most popular Mastodon instances and used regexes to try and find accounts that belong to software developers.

I indexed only a small percentage (0.225% by my count 😅) of all Mastodon instances, but this set of instances includes the majority of English-speaking users on Mastodon (see the full list of instances in the FAQ page).

The results

Count   Instance
2963    mastodon.social
1083    hachyderm.io
513     mastodon.online
447     ruby.social
441     mstdn.social
377     fosstodon.org
361     infosec.exchange
343     mas.to
335     phpc.social
258     techhub.social

No surprise that mastodon.social is on top here. It's one of the largest Mastodon instances with more than 1 million users. That's 1/6 of Mastodon's total users according to mastodon.help. Even though mastodon.social has the most developers of any instance, it also has the most users so the percentage of developers is not that high and your local timeline will most likely not have content relevant to you.

hachyderm.io is an LGBTQIA+ and BLM safe space focused on tech industry professionals worldwide.

mastodon.online is another very popular general purpose instance.

phpc.social and ruby.social are instances for people interested in Ruby and PHP programming languages.

fosstodon.org a community for anyone interested in technology; particularly free and open source software. The custom emojis on this instance are amazing 👌

infosec.exchange focuses on info/cyber security. If that's what you are interested in this is probably the best instance for you!

techhub.social is primarily for passionate technologists, but according to the instance description everyone is welcome.

Breakdown by popular languages

Python developers

Count   Instance
562 mastodon.social
294 hachyderm.io
124 fosstodon.org
108 mastodon.online
100 mas.to
99  infosec.exchange
97  mstdn.social
73  techhub.social
48  mastodon.gamedev.place
35  mastodon.worldCount

The Python community has recently started to migrate away from Twitter and a lot of prominent Python community members no longer post on Twitter.

Besides the two largest instances most Python developers seem to hang out on fosstodon.org. This is where some of the largest Python-related accounts live, including the official account for the Python Software Foundation, Michael Kennedy, Brett Cannon, and others.

JavaScript developers


Count   Instance
448 mastodon.social
299 hachyderm.io
95  techhub.social
89  mas.to
84  phpc.social
82  mastodon.online
74  fosstodon.org
73  mstdn.social
59  ruby.social
38  infosec.exchange

The top two largest instances for JavaScript developers are the same as the Python ones, but fosstodon.org isn't as popular with JavaScript developers as it is with Python developers.

Rust developers

Count   Instance
458 hachyderm.io
226 mastodon.social
57  mastodon.gamedev.place
52  mas.to
49  infosec.exchange
42  mastodon.online
38  fosstodon.org
30  mstdn.social
28  techhub.social
17  chaos.social

Rust developers seem to prefer hachyderm.io over mastodon.social and it seems to be the only programming language with these instances switched.

Ruby developers

Count   Instance
478 ruby.social
151 mastodon.social
118 hachyderm.io
25  mastodon.online
24  mas.to
18  mstdn.social
17  infosec.exchange
15  techhub.social
13  mastodon.world
12  fosstodon.org

No surprise that Ruby developers prefer the ruby Mastodon instance - ruby.social.

PHP developers

Count   Instance
370 phpc.social
200 mastodon.social
38  fosstodon.org
38  mas.to
36  hachyderm.io
31  mastodon.online
24  mstdn.social
15  infosec.exchange
13  mastodon.gamedev.place
12  techhub.social

Similar to Ruby developers PHP developers also have their instance phpc.social. Unlike the Ruby community, it seems like the PHP community is more spread out and the official PHP instance takes up a smaller percentage of users than the ruby.social instance in the Ruby community.

Other popular languages

Fedidevs also allows filtering by Java, C#, Golang, and others. But the amount of accounts isn't as high as the ones listed in this article so I've omitted it for brevity. Let me know if you would still want to see the statistics for these in the comments below.

JSON in Python

Anže Pečar — Sat, 01 Feb 2020 09:11:39 +0000

The JavaScript Object Notation (JSON) is a lightweight data-interchange format that just so happens to be remarkably similar to Python's dict notation.

The two are so similar that you can copy JSON and paste it in the middle of your Python program and it will usually work:

>>> {
...     "my_object": {
...         "my_list": [1, "2", 3.0, 4.0e10]
...     },
...     "my_string": {
...         "escaping": "\"\" 🤔"
...     }
... }
{'my_object': {'my_list': [1, '2', 3.0, 40000000000.0]}, 'my_string': {'escaping': '"" 🤔'}}

Unfortunately, this breaks down whenever you have those pesky booleans or nulls in your JSON:

>>> {
...     "my_null": null,
...     "my_bool": true,
...     "my_second_bool": false
... }
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
NameError: name 'null' is not defined

At this point, you might be tempted to do a search and replace that turns null, true & false into Python's None, True & False, but that's tedious and gets really annoying if you want to copy paste back and forth.

You could even be reasonable and use json.loads but then your JSON would be a string and your editor would no longer color highlight it correctly:

>>> import json
>>> json.loads("""
... {
...     "my_null": null,
...     "my_bool": true,
...     "my_second_bool": false
... }
... """)
{'my_null': None, 'my_bool': True, 'my_second_bool': False}

Because colors are the most important thing in programming, there has to be a better way! And there is. Python allows us to use null, true and false as regular variable names. This means that we can do something like this:

>>> null=None; true=True; false=False
>>> {
...     "my_null": null,
...     "my_bool": true,
...     "my_second_bool": false
... }
{'my_null': None, 'my_bool': True, 'my_second_bool': False}

Marvelous, isn't it? You can even put null=None; true=True; false=False in a separate python file (let's call PJ.py as a shorthand for PythonJson). Now you can do:

>>> from PJ import *

And your python file will be ready to accept JSON!

Do make sure you wear a PJ like the one below when doing this, otherwise, people might think you are being serious 😅

"#ViernesDePijamas" by mrl.itesm2 is licensed under CC BY-NC-SA 2.0

Prefer Books Over Blog Posts

Anže Pečar — Sat, 25 Jan 2020 21:38:30 +0000

Learning how to become a better software developer is a daunting task. There is so much to learn and it seems like everything is changing constantly.

Because of this, it's easy to dismiss books as a resource for advancing your skills. Surely everything that people wrote about 10 years ago cannot still be relevant today, right?

Wrong!

Even though frameworks and even programming languages come and go (or at least become less popular), the concepts behind them stay the same.

The internet is an amazing resource for learning (especially dev.to 😉). But free resources in the form of a 700-word blog post usually cannot even scratch the surface of their topic.

It's also really hard to separate good blog posts from bad ones especially if you are new to the topic they are discussing. Nobody reviews blog posts (the comment section on hackernews excluded). It's even extremely rare to have someone proofread a blog post before posting (yes, nobody proofread this 😅).

Books, on the other hand, are a lot more work. They are written, proofread, edited, rewritten, approved and finally published and printed. Now all of this doesn't necessarily mean that the content is going to be good, but that's where book reviews come in.

As software developers, we will never be able to stop learning. When investing our time we have to make sure it's well spent. Because of this I strongly recommend you prioritize reading books over blog posts. Of course, read everything that you can or want, but try to spend more time on books than blogs.

If you don't know where to start, here's a quick list of books that I think are worth your time. All of them have been published for a long time and are still very much relevant today.

The Pragmatic Programmer by David Thomas, Andrew Hunt
The Phoenix Project by Gene Kim, Kevin Behr (also see The Unicorn Project that came out late last year)
The Mythical Man-Month by Fred Brooks
Code by Charles Petzold
Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Refactoring by Martin Fowler
Test-Driven Development by Kent Beck
Domain-driven design by Eric Evans

Have a book you think every developer should read? Let me know about it in the comments!

Prefer Model.DoesNotExist over ObjectDoesNotExist in Django

Anže Pečar — Sat, 09 Nov 2019 09:00:06 +0000

In Django it's very common to see code like this:

from django.contrib.auth.models import User
from django.core.exceptions import ObjectDoesNotExist
from myproject.apps.teams.models import Team

try:
    user = User.objects.get(pk=1337)
    phone = Team.objects.get(pk=1337)
except ObjectDoesNotExist:
    logging.error("User or Team does not exist")

The code will try to fetch an auth user and a team from the database and if either of those does not exist, we'll just log an error. This is so common that I never thought twice when seeing or writing it.

But it turns out that there is a slightly better way to accomplish the same result. I didn't know this before recently, but the Django Model class has its own DoesNotExist exception! We can use it like this:

from django.contrib.auth.models import User
from myproject.apps.teams.models import Team

try:
    user = User.objects.get(pk=1337)
    phone = Phone.objects.get(pk=1337)
except User.DoesNotExist:
    logging.error("User does not exist")
except Phone.DoesNotExist:
    logging.error("Phone does not exist")

This is better for a couple of reasons:

The two except blocks are now more explicit and will only catch exceptions when the specific model does not exist.
This is minor, but you don't have to worry if ObjectDoesNotExist is already imported in the current scope or not.

MultipleObjectsReturned exception is implemented the exact same way and if you are curious to learn how Django implements a new Exception type for every subclass that you make, you can check out the source code here.

My day job codebase currently has 231 occurrences of except ObjectDoesNotExist. I'll slowly start replacing them with model.DoesNotExist 😊

Reduce Batch Size

Anže Pečar — Mon, 02 Sep 2019 22:04:46 +0000

In the article in the series we learned how important it is to reduce the friction in code reviews, by making code reviews your top priority. Based on the theory of constraints, not working on the bottleneck is counterproductive. If your code review queue is backed up, writing more code will not make you deploy features any faster!

The theory of constraints doesn't only help us figure out what to focus on, but it also has a solution for increasing throughput: Decrease your batch size as much as possible. For us developers, the batch size is the number of code changes that go into each release.

If you are reviewing, testing, and deploying multiple thousands of line changes to save time and increase feature velocity the result you'll get might be the exact opposite. By batching so many changes and features together you increase the lead time for each change. Lead time is one of the four key software delivery metrics according to Accelerate 2018 (other 3 are deployment frequency, time to restore service and change failure rate) and is closely correlated with company performance according to the studies conducted in Accelerate 2018.

Putting it plainly, your big releases prevent small fixes and changes from going out sooner. Bigger releases require more testing, more preparation for deployment and it makes the process even slower. This is how you end up on a release schedule that can take months, is always late, and causes havoc when deployed to production in the form of blocker bugs.

Let's focus on the code review side of things and take a look at why big pull requests are never desired.

Problem with big pull requests

Developers have this joke that a 5 line pull request will have at least 5 comments or change requests while a 1000 line pull request will be accepted immediately with the words "looks good to me".

This is because to properly review those 1000 lines, the reviewer needs to invest a lot of their own time to fully understand the scope of the changes. Those 1000 lines could even be too much for any reviewer to fully comprehend since the number of things that a human brain can keep track of is limited to about 7 items. Often the sheer size of the changes will, at the very least, demotivate the reviewer from doing a good job.

It's often the case that those 1000 lines or more don't change just one aspect of the system. They are usually a group of changes combined to form a whole. Grouping them might be an efficient way for the developer to implement these changes, but usually isn't an efficient way to review, test or deploy them.

Let's take a look at how big pull requests can be broken down into smaller ones that are easier to review, test, and deploy.

Avoid batching features in a single pull request

We are often tempted to fix or complete multiple tasks while working on a particular part of the codebase and then combine all those changes in a single pull request.

An example of this could be a pull request that fixes a production issue and improves logging around that issue.

When reviewing this pull request a potential problem with the code that adds the logging could delay the merge of the code that fixes a production issue. Your users will be stuck with the bug while you are fixing a logging issue that your users don't even know exists.

When you write and in your PR title consider opening two pull requests instead. This will help the reviewer focus on one problem at the time, making it less likely for mistakes to go through.

This point is even more severe if the issue pops up only when the code is deployed. If there is an issue with the logging code, you might have to revert the bugfix as well to resolve the problem. Not a good place to be in.

Small code batches

If you had been burnt by the issue above and then decided to vigilantly deploy only one feature at a time, you still occasionally run into issues. Features that are useful to your customers tend not to be just a change to a few lines of code. Instead, they require days or even weeks of work before they become useful.

Checking in code after weeks of work tends to be painful. You'll be working on a feature branch and will need to deal with merges and conflicts. And in the end, you'll have a big merge into your master branch, followed by the big deployment of what was probably months of work put into a feature branch.

The only solution to this is to decouple features from code changes.

Decouple Features From Code Changes

The only way to address these issues is to avoid having long-running feature branches in the first place. Instead, all the changes should be reviewed and merged into your develop branch as soon as possible. This means deploying code that's not yet ready to be run on production and is therefore hidden from the word in a form of a feature flag.

LaunchDarkly raised $44 million this year helping programmers achieve exactly that, but in most cases, a simple ENV variable or a setting flag should be all you need to make sure the feature is not enabled until the last piece is merged and deployed.

The technique described above is called Trunk Based Development and it tries to address some issues of the GitFlow development model. Most importantly it helps us reduce the batch size for code reviews and helping us speed up feature lead times.

It isn't perfect, of course. Now that you are merging things into master immediately after review, you might end up with dead code in your codebase when the priorities of the project shift. Even if this code is guarded by feature flags it can still pop up in unexpected ways and cause a production issue if there is a problem with your configuration, so you will need to spend some time every few sprints to clean it up.

Do you have a better way of dealing with big pull requests? Let me know in the comments below.

The Code Review Bottleneck

Anže Pečar — Thu, 29 Aug 2019 10:34:29 +0000

Code reviews are really useful, but the problem is that they have the nasty habit of making your cool new feature stuck in the queue waiting for reviewers. Let's take a look at how to make sure code reviews are done as efficiently as possible. Let's see how we can do quality code reviews without impeding feature velocity.

The Bottleneck

Code reviews are by their nature a bottleneck. They slow down the flow of features on their way to production. In this sense, they work against your goal to ship quality features to your customers as fast as possible. But because code reviews help your team ship fewer bugs and higher quality features they are worth the downside.

The faster you can ship new features the better your company can adjust to new market trends and resolve user issues. Teams that can deliver in weeks outperform teams that deliver in months or even years.

If your pull requests are pilling up and staying open for weeks it might be a sign that your process could use some improvement.

The Wait Time

The biggest issue with code reviews is the wait time.

When the author of the code opens a pull request and marks it ready for review, they need to wait until another person comes along and reviews it. This could be 1 hour after the pull request has been opened (if you are lucky) or it might take a few days or even weeks (if you are not lucky).

After the first review is posted there is almost always a bit of wait time again, before the author sees the review, and then even more if the author needs to adjust the code based on the feedback.

This process can go on for multiple cycles and every handoff adds another bit of wait time. This is how a simple feature that was ready 2 weeks ago still hasn't shipped yet.

The wait time is especially painful for us programmers because, after each wait time, the context is lost and needs to be rebuilt again. The longer the wait time the more difficult it is to remember how all the code changes fit together into the shippable feature.

The Solution

There is only one way to resolve the wait time issue. It is to try to minimize it as much as possible. The best way to accomplish this is to make code reviews the top priority for your team.

When a pull request is ready for review, the reviewers should drop everything and focus on getting it reviewed and merged ASAP. The wait time between handoffs should be measured in minutes and not hours or days.

When a pull request is reviewed and needs updates, the author should drop everything and focus on responding to comments. Again trying to limit the wait time to minutes and not hours if possible. If the review requires a substantial amount of code changes you should discuss it with reviewers to make sure changes will bring business value to customers.

The "drop everything because of code reviews" rule is counter-intuitive for us developers. We like to be in the flow and don't want to break out of it for whatever reason. This is how we feel productive. Code reviews don't make us feel productive because we will not be credited when the feature ships. Usually, it's the author that will take all the credit.

If you follow the rule of code reviews being the top priority your personal productivity will take a hit.

But the productivity of your team will soar

Your personal productivity is not even remotely as important as the productivity of your team. Your team is most productive when it's shipping features to users. When a feature is ready for code review the developer is saying it's ready to be deployed to production. Your team's most important goal at this point needs to be to make sure the code is shippable.

Anything other than doing the code review is counterproductive for your team. If you spend the rest of the day working on your feature instead of reviewing a pull request, you're blocking a feature from being deployed. Even worse, you are creating a new bottleneck and creating more work in progress which will cause even more context switching down the line.

This is how pull requests pile up and feature velocity plummets.

It's absolutely crucial to make the code reviews the top priority. When a code review comes in you need to stop all other nonproductive activity. This is pretty much anything except maybe firefighting a production issue affecting your customers.

You will be my hero if you say that the current meeting needs to end earlier because you need to go review a newly opened pull request. 🤙

In the next blog post, we'll take a look at some techniques you can use to make it possible to review and merge pull requests as quickly as possible. Spoiler: it's all about reducing the batch size!

Code Reviews and the Company Goal

Anže Pečar — Tue, 27 Aug 2019 00:07:49 +0000

Code reviews are an important part of how we write code today. It's pretty rare to find a company that doesn't practice code reviews in some shape or form. If the drivers for doing code reviews in the company aren't engineers it's regulation. Code reviews have become a compliance requirement for some security standards (e.g. PCI DSS 3.0)!

The popularity of code reviews is due to the fact that they bring multiple benefits to the engineering process:

Ability to catch code defects before the code is shipped to QA or prod.
Sharing knowledge with the team.
Increase a sense of mutual responsibility.
Improve code quality.

Due to all these benefits, we engineers probably all agree that code reviews are necessary to ship stable code to production. But as engineers, we also need to keep in mind how our processes affect our companies. It's important that we ask ourselves how the code review process helps our companies achieve their goal.

The Goal

According to Eliyahu M. Goldratt and his novel The Goal, the goal of most companies is to make money:

Suddenly it strikes him that the Goal of his company is to make money! Anything that brings him closer to the Goal is productive. Hence, all other activities are non-productive!

Even though The Goal talks about manufacturing and operating a manufacturing plant, most of the ideas apply to other types of processes as well. Read The Phoneix Project to see how The Goal can be applied to IT.

Are code reviews actually a productive activity for the company? As mentioned above, they have a lot of benefits, but they also take precious engineering time away from writing code plus they increase the lead time for new features. Would it be more productive to use that time to write more code instead? The answer to this is no, but only if code reviews are conducted in an efficient manner. When done wrong, even though the intentions were good, they can actually have negative results.

A bad example

The CTO of Acme inc is obsessed with code quality and sharing knowledge between the engineering team. So much so that the CTO proposes a process that requires every code change to be reviewed by all developers in the engineering department (more than 10 people!).

What are the impacts of this new process to the company?

This new process will increase code quality as all these reviewers will find more issues with the code than a single or two reviewers ever could. 👍
This new process will also increase knowledge sharing. Every engineer on the team will see every change going out. 👍
But this process will make feature velocity grind to a halt. All the engineers will be too busy reviewing all the code! 👎

The company will struggle if releasing new features to the customers will require this many reviews, so even though the intention was a noble one, it will actually hurt the company's goal.

The road to hell is paved with good intentions.

I have seen a much milder version of this first hand and it wasn't at all obvious that we were doing something counterproductive. We were just focusing on the wrong things when reviewing code, making code reviews too rigid and making the process take too much engineering time without bringing enough value.

So to properly understand how to structure our code review process, let's look at all the main benefits from the list above and see how much value they bring to the company's goal. This will help us figure out what we need to focus on the most when reviewing code.

1. Catch code defects before the code is shipped to QA or prod

During my career I have heard the following phrase multiple times:

Code reviews aren't there to catch bugs, we have the QA team for that.

But if you are looking at code reviews from the standpoint of the value that they bring to the company, detecting issues early is probably the biggest impact that a code review can make. It's definitely the only thing that the users will notice!

Even if you have an amazing QA team that makes sure that bugs don't get deployed to production, there is still the value of finding bugs during the code review process. Fixing the bug found during code review will be much easier and quicker as it will require fewer people to be involved. You might not even need a Jira ticket for it! This will increase your turnaround time and make sure users get your new feature sooner. Quick turnaround time adds value to your company.

Finding bugs is extremely important, but as a reviewer, you also shouldn't spend hours reviewing the code and trying out every edge case by hand. Instead, what you should do is focus on finding bugs when reading through the code as opposed to focusing on styling issues.

Take special care when you see branches in the code path, ask yourself if both branches are covered by tests. Also, pay attention if the author forgot to handle an error case. When you see something that you think might cause a bug, ask the author to write a test to cover that edge case.

According to the company's goal, finding bugs early at the very least allows us to fix defects sooner, allowing us to deploy the new feature to the customers faster. It also helps make sure you don't slip a bug through the cracks and push it to production where it might annoy your users. From this perspective, finding a bug during the code review process is probably the most productive thing that you can do for your company.

2. Share knowledge with the team

Every code review is a chance to learn something new. Both for the author of the code and for the reviewers. As a reviewer, you can learn how other people on your team solve problems. As the author, you get feedback on your work which is crucial for self-improvement.

How does sharing knowledge help the goal of your company? It does very little to impact the users directly so this aspect of code reviews is in my opinion not as important as the one described in the previous chapter.

But sharing knowledge still helps your company as it reduces the bus factor - the measurement of the risk resulting from information and capabilities not being shared among team members. It also integrates learning and self-improvement into your engineering process which is crucial for your company to grow.

So make sure you look for ways to share knowledge when doing code reviews, but only after you are sure that you can't find any defects with the code.

3. Increase a sense of mutual responsibility

Your whole team needs to own their code collectivity. If a single person is responsible for a part of the system it's a risk for your business as that person will be the bottleneck for every new feature that touches that part of the system. Bottlenecks like this can bring your feature velocity to a standstill, so it's always a good idea to see if you can reduce them.

This doesn't directly impact the company's goal, but it can still have a huge impact indirectly. Make sure that you share as much knowledge as possible during the code review process to avoid bottlenecks like the one described above.

4. Improve code quality

Code reviews are a good way to catch little improvements to the code. It feels great when you point out that a few lines of code can be deleted because there is already an existing function that does the same thing.

But be careful, being overly pedantic about every little style issue can have negative impacts on the productivity of your team!

I have seen requesting a whitespace delay the new feature from shipping for a few weeks because the change request made it miss the release window. Be mindful of how much company value is gained by making code style comments and perhaps rather invest some time to automate this into your test suite or the use of an autoformatter.

Try to make sure code style issues are detected automatically, without human interaction. After that only mention styling issues only when there are no bugs to point out or there is no way to share knowledge. And if the reviewer doesn't agree with the change, don't persist.

Conclusion

Be mindful of the company goal when doing code reviews. Ask yourself how much value your code review comment brings to the table. If you are asking to change some whitespace, the value will be very small. If you are asking to change the code that might misbehave under certain conditions exposing sensitive customer data, the value will be huge.

When doing code reviews, try to write more comments with a higher value than lower value.

Learned something new? Be sure to share what you've learned with your team. Sharing knowledge is one of the most important parts of your job 😉

In the next blog post, I'll talk about how to make sure code reviews have as little impact on feature velocity as possible. Sign up below to get the article in your inbox as soon as it's ready.