Professionalism And The Software Industry

A couple of months ago I had a longish, nuanced, healthy discussion on Mastodon about professionalism in software development, and I thought it would be useful for me to summarise most of my views on the matter in a blog post, because that’s what I do after all. As usual, this post reflects my personal opinions, not those of my employer.

I have touched upon professionalism once or twice, though I never really tried to discuss directly what I see as being “professional behaviour” nor I have spent any significant time talking about my general feelings for qualifications, professional bodies, and the like, even when I have spent enough time thinking about them, particularly around my own career. Trying to put all of this into a consistent, and possibly relatable article is going to be… not easy. So please bear with me.

The first thing I want to make clear, is that I neither want to, nor would be the right person to, gatekeep what “professionalism” is. Indeed, I believe that different people can have different views of what is and is not professional for them, and I’m not looking to invalidate it, I just want to share how I personally see this.

Indeed, my own views of professionalism have been, early on, influenced by two people who took their own take on professional: Robin Johnson and Donnie Berkholtz, from Gentoo Linux. Both of them are people I look up to in terms of both professionalism and ability, and while as I said they influenced my view on professionalism doesn’t follow directly on either of them — and indeed it would be hard for me to distinguish now what inspired me from either of them: my professionalism is my own, but built on the shoulder of giants, like most of my work philosophy and general life views.

So let’s start with a straw-man view of professionalism which is oft-repeated, and was where the conversation on Mastodon has started. There’s a misconception that professionalism is the diametrical opposite of “fun” — so as long as you’re not fun, you’re professional. No jokes, no sparkles, no pride in your job. That whatever you do, you shouldn’t put your opinion forward, and be quiet not to upset whoever.

I don’t think that is the core of what professionalism is. There’s definitely a grain of truth in it, as I would expect professionals not to put jokes in bad tastes, or look to upset the people they work with. And as I said in the other post, when you’re working at a company (big or not), it would be unprofessional behaviour not to follow the handbook when it comes to providing feedback, for example by loudly criticise your employer in public — which does not mean defending your employer in public, whether deserved or not!

The reason why I believe that you should be respecting your employer, is because professionalism to me means respecting obligations and contracts. If I don’t believe in the obligations anymore, in my view I should see a way to cleanly break out of them, not to simply ignore them. Which is where I see my first strong interplay between professionalism and ethics, and why I believe they are distinct views to take. It is my professionalism that keeps me to my obligations, it’s my ethics that could see me walk away from them (following the process set my professionalism!)

Speaking of kernels of truths, I said earlier that “being professional” doesn’t mean not having fun, but to avoid jokes in bad taste. The problem here is that what is a joke in bad taste changes dramatically depending on who’s reading it, which is where the idea that being professional means not having fun is likely coming from. When you’re not sure how a joke is going to be taken, it’s almost always better to avoid jokes altogether. It also means being mindful that even innocent in-jokes that do not attempt to poke fun at people are often not very inclusive, and you never know when they will turn out to not be funny anymore by association.

Personally, I prefer keeping the “fun” in my professional life to ephemera, and to what is more clearly my personal views and spaces. So I have no problem with furry art, but my shared projects have the most boring and descriptive names you can come up with. This has the side effect of generally not requiring me to worry about the risk of them violating trademarks, or be stolen by the Mozilla Project.

At the same time, I don’t believe there’s an expectation that professionalism require “Western shaped names” as some people seem to imply. I say “Western shaped” because there’s quite a bit of leeway within what people seem to accept as a “real name” that can reveal quite a bit of biases, but in any case, I do not believe that naming has anything to do with professionalism. Even the FT managed to refer to Zatko as Mudge (although they do seem to prefer the western-shaped name as part of their styleguide) — and while I do use my full legal name in most of my accounts (among other reasons, because I chose my first name when I changed it back in 2008!), all my account names and email address are indeed assigned to Flameeyes. I would tell you one more thing: at work my profile is named Diego Elio Flameeyes, admittedly mostly for practicality (no accents there), which means most people, including my manager, HR, and my leadership know me by that name.

This also works as a segue for another related topic: my distinction of software as art versus software as industry, which is a distinction that is fairly permeable: while I find myself almost always thinking of myself as part of industry, I do end up sometimes acting like artistry. The main difference between these two modes, to me, is whether you’re doing something primarily for personal pride and accomplishment, or as a part in a system that goes beyond your own contributions. You could call this “art” mode “maker” mode as well, if you want to fit this into the same view as the makers’ movement that Adam Savage has been a prominent speaker of.

I do want to make it clear here, that with the “beyond your own contributions” I do mean that the software industry does not include only Big Tech or the work of software companies and consultancies. When you write a Free Software project with the intention for others to adopt it, you’re making yourself part of something bigger than your own contribution.

When you build something but you don’t want anyone else to use it, even if you decide to share it with the world, you may be interested in explicitly not being part of an industry, for one reason or another, which is fine by me, I don’t expect that something released in such a manner would ever need to think about professionalism in the first place.

But once you do share something with the world, with a compatible license, and utility, you are, willing or not, part of the Industry as a whole — whether you do want to be professional about it, is entirely up to you though. On the other hand, the way other members of the industry will treat and consider will depend on said professionalism.

Of course, it’s important to know that professionalism goes both ways: if you’re engaged in a commercial activity and expect to get free support from a FLOSS developer, you should not just be ashamed of yourself, but have a deep thought about what you’re doing in terms of your own sustainability. But at the same time, if you’re a maintainer of a project and you want to invite commercial actors to use it and contribute, you almost certainly will need to put up with the way commercial actors do business — which primarily, in my experience, is to understand and accept that those commercial players have customers of their own, and that almost always their primary intent is to make money.

A few too many times I have seen FLOSS maintainers complain that nobody is paying them to just keep doing what they are doing, and that even commercial players who want to give them money want to attach strings to them. I empathise with this feeling, but at the same time I realize that this is almost always the only way for a small to medium company to approach an open source maintainer: they most likely have tight margin themselves and are unable to just wait for the maintainer to get around to fix whatever they need fixed. Whether you like it or not, most of us live in some shade of a capitalistic society, and we need to work to pay bills and enjoy our lives.

Do note that here I’m not saying that every FLOSS maintainer needs to feel compelled to accept contributions (monetarily or not) or support requests (paid or not) from any company, whether they want it or not! There’s definitely a number of companies that I would never do business with (including but not limited to gambling, which also means cryptocurrencies) and if approached I would more-or-less politely decline — politely when I have an ethical disagreement with the venture, less politely if I believe they are a bane of society and complete destruction of the environment.

This is part of professionalism for me: I disagree with the direction that companies take all the time, but that doesn’t mean I’m going to abuse the people who reach out to me, for whichever reasons they did it. Don’t burn bridges unless you really feel you have to. And if you do accept a contribution from a company, well, it’s up to your professionalism whether to engage in criticism of your partners, but if you do you may need to disclose said contributions, and also give a heads’ up to your contacts, so that they have a chance to address your criticism, in my opinion. (This is very situational, there are definitely cases in which giving them a chance to know you are about to criticize them might backfire, so always take it with a grain of salt and plan ahead.)

Speaking of contributions, I also want to very briefly address the elephant in the room that is “That one guy in Nebraska.” I really dislike this comic and the way it is used in FLOSS discourse nowadays! I don’t know how Randall Munroe sees it exactly in terms of what the comic ends up representing, but to me it’s often paraded around in the worst possible of ways I can think of.

First of all, yes, it’s true that there’s definitely a ton of systems and services out there that end up relying almost exclusively on one or two people maintaining a piece of code that basically always work – until it doesn’t – and are likely overworked and underappreciated. Often enough, people talk about curl that way, with Daniel Stenberg as the guy in Nebraska — although it is my understanding that he’s actually paid to work full time on curl, and there’s probably a lot more topical cases of people working with zero support and reward behind them.

But the reason why this whole comic upsets me is that I see people using it as an excuse or even an aspiration. Some of them think that we should keep the guy in Nebraska in the same position, and make sure they are full of rewards. Others want to be the person in Nebraska that alone hold together half of the modern Internet, because they believe it’s cool. In either case, I believe that the solution is wrong (professionally, and ethically.)

I believe that in the situations that do exist of “the one guy in Nebraska”, the action to take is making sure that it’s no longer only one person holding up a complex system! This means at times building governance structures, and at times deciding that it’s not possible to rely on a project that is supported by one person only — which means forking or rewriting. While licensing terms very obviously had their part, it was not impossible to understand that Apple’s reliance on GCC, with a certain project-dictator in charge, would not have scaled long term.

Speaking of licensing, I have also seen at times people “surprised” (I’m never sure if they are really surprised because they don’t understand the reasoning, or if they play the surprised rethorics for their own purposes) when commercial enterprises decide to not use an existing hard-copyleft project in favour of reimplementing the idea or functionality in a soft-copyleft or even not copyleft project by themselves. This is particularly cringy when discussed in reference to AGPL-3 licensed projects, since the license is pretty much kryptonite for commercial actors.

I think this is going to be it from my side, at least for now. On Mastodon I have taken a side discussion about professional bodies as well, but I don’t feel like going down that route here, since it is a topic that I would have to brush up on before discussion. On the other hand I’m more than happy to dig into more details of what I discussed here, if anyone is interested — tell me over socials or in the comments below this article. I know the stream of consciousness I’m using here is not very conductive to build a consolidated view on professionalism, but I’m not setting out to write a Harvard Business Review style article, I’m just sharing my view with the world, take it however you please!

#Jobs #Professionals #WorkPhilosophy
On professionalism (my first and last post explicitly about systemd)

I have been trying my best not to comment on systemd one way or another for a while.…

Flameeyes's Weblog
Telling New Stories About Work Beyond Capitalism
When it comes to our working lives, the stories we tell ourselves, and more importantly the stories the world tells about us influence not just the jobs we get, but also how we feel about ourselves and our work. The statistics about neurodivergent (not just Au
https://unscramblet.chickenyogi.com/telling-new-stories-about-work-beyond-capitalism/
#entrepreneurship #WorkPhilosophy #anticapitalism #neurodivergent #WorkWellness #WorklifeBalance
Telling New Stories About Work Beyond Capitalism - Unscramblet by Chicken Yogi

When it comes to our working lives, the stories we tell ourselves, and more importantly the stories the world tells about us influence not just the jobs we get, but also how we feel about ourselves and our work. The statistics about neurodivergent (not just Autistic or ADHD, but the entire neurodivergent umbrella) people and

Unscramblet by Chicken Yogi - Work-life balance without getting scrambled
What would a neurodivergent small business incubator look like?
I've been in the entrepreneur space since 2007, and it wouldn't be a lie to say that I've struggled most of that time. I've listened to coaches and webinars, free
https://unscramblet.chickenyogi.com/what-would-a-neurodivergent-small-business-incubator-look-like/
#entrepreneurship #WorkPhilosophy #WorkWellness #ADHD #AuDHD #AutisticBusinessOwner #AutisticownedBusiness #entrepreneur #SmallBusinessIncubator #SmallBusinessOwner
What would a neurodivergent small business incubator look like? - Unscramblet by Chicken Yogi

I've been in the entrepreneur space since 2007, and it wouldn't be a lie to say that I've struggled most of that time. I've listened to coaches and webinars, free summits, and podcasts, and there's one thing I realized...most of that information is geared toward someone with 1) time 2) money and 3) an innate

Unscramblet by Chicken Yogi - Work-life balance without getting scrambled
Migrations and Attention Budgets

Please note, this blog post talks about concerns that are mostly known about in big companies (mainly Big Tech), rather than in smaller realities or in FLOSS. While some of the issues I’m goi…

Flameeyes's Weblog
We Need Cooperation Within The ND Entrepreneur Space
It's lonely being a solo business owner, an entrepreneur...whatever term you use, it's pretty lonely. One of the main reasons why it feels so lonely is that too often getting the word out about the wo
https://unscramblet.chickenyogi.com/we-need-cooperation-within-the-nd-entrepreneur-space/
#Business #WorkMentalHealth #WorkPhilosophy #AuDHD #Autism #CooperativePromotion #entrepreneur #neurodivergent #SmallBusinessOwner #SocialMediaPromo
We Need Cooperation Within The ND Entrepreneur Space - Unscramblet by Chicken Yogi

It's lonely being a solo business owner, an entrepreneur...whatever term you use, it's pretty lonely. One of the main reasons why it feels so lonely is that too often getting the word out about the work you do, the creations you make, seems to be a pretty difficult venture. Social media algorithms are designed to

Unscramblet by Chicken Yogi - Work-life balance without getting scrambled

Just because it looks like a number of people started following me in here that might not know me from elsewhere.

I'm effectively a not-so-current FLOSS developer that for most of the last two years has been writing only about #WorkPhilosophy.

Feel free to read at https://flameeyes.blog/tag/work-philosophy/

Work Philosophy – Flameeyes's Weblog

Posts about Work Philosophy written by Flameeyes

Flameeyes's Weblog

So much going through my head right now about reinventing my business in the new year.

- I want to be of help without being spread thin. i.e. a more clear focus and niche
- I want to be able to work from home
- I want to continue publishing free blog posts and newsletters
- Maybe have time over to start a new book
- Maybe more writing than designing
- Maybe more teaching than doing

That's where I am today. Right now.

#WorkPhilosophy

On Rake Collections and Software Engineering

Illustration by Furryviza

https://twitter.com/flameeyes/status/1255925549752614913

Matthew posted on twitter a metaphor about rakes and software engineering – well, software development but at this point I would argue anyone arguing over these distinctions have nothing better to do, for good or bad – and I ran with it a bit by pointing out that in my previous bubble, I should have used “Rake Collector” as my job title.

Let me give a bit more context on this one. My understanding of Matthew’s metaphor is that senior developers (or senior software engineers, or senior systems engineers, and so on) are at the same time complaining that their coworkers are making mistakes (“stepping onto rakes”, also sometimes phrased as “stepping into traps”), while at the same time making their environment harder to navigate (“spreading more rakes”, also “setting up traps”).

This is not a new concept. Ex-colleague Tanya Reilly expressed a very similar idea with her “Traps and Cookies” talk:

https://www.youtube.com/watch?v=iMSBuNaJh7A

I’m not going to repeat all of the examples of traps that Tanya has in her talk, which I thoroughly recommend for people working with computers to watch — not only developers, system administrators, or engineers. Anyone working with a computer.

Probably not even just people working with computers — Adam Savage expresses yet another similar concept in his Every Tool’s a Hammer under Sweep Up Every Day:

[…] we bought a real tree for Christmas every year […]. My job was always to put the lights on. […] I’d open the box of decorations labeled LIGHTS from the previous year and be met with an impossible tangle of twisted, knotted cords and bulbs and plugs. […] You don’t want to take the hour it’ll require to separate everything, but you know it has to be done. […]

Then one year, […] I happened to have an empty mailing tube nearby and it gave me an idea. I grabbed the end of the lights at the top of the tree, held them to the tube, then I walked around the tree over and over, turning the tube and wrapping the lights around it like a yuletide barber’s pole, until the entire six-string light snake was coiled perfectly and ready to be put back in its appointed decorations box. Then, I forgot all about it.

A year later, with the arrival of another Christmas, I pulled out all the decorations as usual, and when I opened the box of lights, I was met with the greatest surprise a tired working parent could ever wish for around the holidays: ORGANIZATION. There was my mailing tube light solution from the previous year, wrapped up neat and ready to unspool.

Adam Savage, Every Tool’s a Hammer, page 279, Sweep up every day

This is pretty much the definition of Tanya’s cookie for the future. And I have a feeling that if Adam was made aware of Tanya’s Trap concept, he would probably point at a bunch of tools with similar concepts. Actually, I have a feeling I might have heard him saying something about throwing out a tool that had some property that was opposite of what everything else in the shop did, making it dangerous. I might be wrong so don’t quote me on that, I tried looking for a quote from him on that and failed to find anything. But it is something I definitely would do among my tools.

So what about the rake collection? Well, one of the things that I’m most proud of in my seven years at that bubble, is the work I’ve done trying to reduce complexity. This took many different forms, but the main one has been removing multiple optional arguments to interfaces of libraries that would be used across the whole (language-filtered) codebase. Since I can’t give very close details of what’s that about, you’ll find the example a bit contrived, but please bear with me.

When you write libraries that are used by many, many users, and you decide that you need a new feature (or that an old feature need to be removed), you’re probably going to add a parameter to toggle the feature, and either expect the “modern” users to set it, or if you can, you do a sweep over the current users, to have them explicitly request the current behaviour, and then you change the default.

The problem with all of this, is that cleaning up after these parameters is often seen as not worth it. You changed the default, why would you care about the legacy users? Or you documented that all the new users should set the parameter to True, that should be enough, no?

That is a rake. And one that is left very much in the middle of the office floor by senior managers all the time. I have seen this particular pattern play out dozens, possibly hundreds of times, and not just at my previous job. The fact that the option is there to begin with is already increasing complexity on the library itself – and sometimes that complexity gets to be very expensive for the already over-stretched maintainers – but it’s also going to make life hard for the maintainers of the consumers of the library.

“Why does the documentation says this needs to be True? In this code my team uses it’s set to False and it works fine.” “Oh this is an optional parameter, I guess I can ignore it, since it already has a default.” *Copy-pastes from a legacy tool that is using the old code-path and nobody wanted to fix.*

As a newcomer to an environment (not just a codebase), it’s easy to step on those rakes (sometimes uttering exactly the words above), and not knowing it until it’s too late. For instance if a parameter controls whether you use a more secure interface, over an old one you don’t expect new users of. When you become more acquainted with the environment, the rakes become easier and easier to spot — and my impression is that for many newcomers, that “rake detection” is the kind of magic that puts them in awe of the senior folks.

But rake collection means going a bit further. If you can detect the rake, you can pick it up, and avoid it smashing in the face of the next person who doesn’t have that detection ability. This will likely slow you down, but an environment full of rakes slows down all the newcomers, while a mostly rake-free environment would be much more pleasant to work with. Unfortunately, that’s not something that aligns with business requirements, or with the incentives provided by management.

A slight aside here. Also on Twitter, I have seen threads going by about the fact that game development tends to be a time-to-market challenge, that leaves all the hacks around because that’s all you care about. I can assure you that the same is true for some non-game development too. Which is why “technical debt” feels like it’s rarely tackled (also on the note, Caskey Dickson has a good technical debt talk). This is the main reason why I’m talking about environments rather than codebases. My experience is with long-lived software, and libraries that existed for twice as long as I worked at my former employer, so my main environment was codebases, but that is far from the end of it.

So how do you balance the rake-collection with the velocity of needing to get work done? I don’t have a really good answer — my balancing results have been different team by team, and they often have been related to my personal sense of achievement outside of the balancing act itself. But I can at least give an idea of what I do about this.

I described this to my former colleagues as a rule of thumb of “three times” — to keep with the rake analogy, we can call it “three notches”. When I found something that annoyed me (inconsistent documentation, required parameters that made no sense, legacy options that should never be used, and so on), I would try to remember it, rather than going out of my way to fix it. The second time, I might flag it down somehow (e.g. by adding a more explicit deprecation notice, logging a warning if the legacy codepath is executed, etc.) And the third time I would just add it to my TODO list and start addressing the problem at the source, whether it would be within my remit or not.

This does not mean that it’s an universal solution. It worked for me, most of the time. Sometimes I got scolded for having spent too much time on something that had little to no bearing on my team, sometimes I got celebrated for unblocking people who have been fighting with legacy features for months if not years. I do think that it was always worth my time, though.

Unfortunately, rake-collection is rarely incentivised. The time spent cleaning up after the rakes left in the middle of the floor eats into one’s own project time, if it’s not the explicit goal of their role. And the fact that newcomers don’t step into those rakes and hurt themselves (or slow down, afraid of bumping into yet another rake) is rarely quantifiable, for managers to be made to agree to it.

What could he tell them? That twenty thousand people got bloody furious? That you could hear the arteries clanging shut all across the city? And that then they went back and took it out on their secretaries or traffic wardens or whatever, and they took it out on other people? In all kinds of vindictive little ways which, and here was the good bit, they thought up themselves. For the rest of the day. The pass-along effects were incalculable. Thousands and thousands of soul all got a faint patina of tarnish, and you hardly had to lift a finger.

But you couldn’t tell that to demons like Hastur and Ligur. Fourteenth-century minds, the lot of them. Spending years picking away at one soul. Admittedly it was craftsmanship, but you had to think differently these days. Not big, but wide. With five billion people in the world you couldn’t pick the buggers off one by one any more; you had to spread your effort. They’d never have thought up Welsh-language television, for example. Or value-added tax. Or Manchester.

Good Omens page 18.

Honestly, I often felt like Crowley: I rarely ever worked on huge, top-to-bottom cathedral projects. But I would be sweeping around a bunch of rakes, so that newcomers wouldn’t hit them, and that all of my colleagues would be able to build stuff more quickly.

#Development #Maintenance #SoftwareEngineering #Traps #WorkPhilosophy

FurryViza

A small Furry Artist - She/Her

FurryViza