DEV Community: Peter Aba

Revised: The danger of detached management

Peter Aba — Fri, 08 Dec 2023 13:42:00 +0000

This post was originally posted on my blog. The original version you can find here.

Preface

4.5 years ago I wrote a little blog post that I’d like to republish, after spending 4 more years in management. Note that at the time of writing of the original piece, I’ve had roughly 3 years of management experience and I had managed about 5-7 people in total. Since then, I spent another 4 years in management and have managed another 15-20 people at least. Below is a slightly revised version of the original post, which is still available here. If you’ve read that post, you can script straight to the solutions section.

Scenario - The good parts

So let's say you have a software feature team made up of a handful of focused and experienced professionals and perhaps a few juniors just for good measure. Let's also imagine that this is true for both the engineers and the product managers. Let's say they together manage to implement a very fruitful culture where things to deliver and their priorities are always clear. Things also get delivered more or less on time and technical debt is also kept under control. Sounds great so far, right?

To color that picture a bit further, let's also imagine that this imaginary team has some process in place to improve their internal processes and discuss pressing issues. For example, they might meet regularly for Kaizen meetings to keep things generally improving.

Now let's say that said team also has a lead, but that lead is mostly involved in high level discussions, long term plans and in some cases aligning with other teams on said long term plans and their execution. She has her calendar full of meetings with stakeholders and upper management while she also takes part in the hiring process.

Impact - The bad parts

It's obvious that she lifts a lot of weight off the team's back, practically enabling them to focus on the product and engineering tasks. I suppose this should still sound great, there's hardly anything to boost team performance more than cutting out distractions. The problems start when she decides not to have one-on-one's with her team members since she's not really part of the team's day-to-day work. She also considers attending stand-ups and Kaizens to be optional for her. This however can render her practically detached from her team.

These actions can and will in-effect the team in a few ways.

1. Hard to get help

Perhaps least importantly, if and when there is a problem that the team can not solve themselves, it will be harder to get the lead to make good decisions or even weigh in, because first she’s not used to weighing in on team issues, and second she might lack some important context which is not always easy to obtain on the spot.

2. Awkward team activities

Team members may also feel somewhat awkward or even anxious around a detached lead as she may be seen as some sort of outsider without sufficient amount of regular interaction. As a consequence, this may also poison team activities such as team events to some extent, simply because some might feel less ready to open up in front of someone who has not earned their trust. This is probably more of a problem for introverted team members, but still worth mentioning.

3. Lack of trust

Lack of touch can also cause a lack of transparency and team members might start wondering what their lead is doing most of her time and whether she has enough insight into the teams' work to be able to properly represent them in long term planning sessions with other managers.

4. Understanding team performance

Let’s say the OKR says product X will be delivered by the end of the quarter but then some urgent request comes up that pushes the team to deliver product Y first. Or perhaps there’s also a dependency on team Z to deliver product X and they’re late. Either way at the end of the business quarter product X is not delivered, therefore a detached manager may think that the overall performance of our imaginary team is less than great. Needless to say, technical improvements throughout the quarter might go unnoticed even more easily of course.

5. Understanding individual performance

Team members might be judged on weird measures like being typically vocal or less vocal during selected meetings attended by the lead. Imagine if that was being used as a deciding factor for your relative performance compared to the team average. This can of course further lead to team members getting unfair and unhelpful promotion feedback, which will inevitably force valuable employees to seek better treatment and potentially promotions elsewhere.

Another common consequence is looking at somewhat artificial numbers like tickets reviewed, tickets closed, number of lines changed, etc. (While I don't think I was ever really detached from my teams, I'm also guilty of this, I plan to write about this in some later post.)

6. Creating legacy systems

Possibly the most important consequence of such unfair feedback is that people who don't quit will typically adjust. When technical greatness is not appreciated, people will simply focus on product delivery and quality will naturally decline. In software development this means that eventually the system will become a mess that no one wants to touch anymore. When this happens, the lead will have her job failed as hard as possible, no matter how great a job she does doing her day-to-day job.

When closed tickets and similar are used to measure performance, engineers will adjust, and in extreme cases they might create a new ticket for the tiniest of things, which will obviously make them less performant as they'll spend more time with administration, then development. (More about that in some later post.)

I imagine most of the above would apply to any delivery team, in or outside of IT, however with software feature teams there's an extra risk: Whether the product delivered is of poor or great quality can be very hard to tell. Yes, if the live system is broken every second day, that's a clear sign. Or in case the UI is not usable, it's easy to assume that the code is one big pile of stinky brown material. However, the complexity of even the simplest software systems is still more complex than most other products in life and this means even software that does a decent job on the surface might be less than pleasant to work on as an engineer. When a leader is detached from the team, there's a good chance that she'll only realise the poor state of the system her team manages when people are already leaving or have left as a consequence. (This tends to be the story behind most, if not all, "legacy-refactoring" projects.)

Solutions

Here's what I think our imaginary lead should do:

She should create rapport with her team members. Regular one-on-ones should be considered a foundation for that. If applicable, she should even schedule regular skip-level one-on-ones.
She should make sure to be present in some team meetings regularly which shows that she cares about team dynamics. (In the above scenario, this would mostly mean the Kaizen meetings.) It's okay for her to weigh in on issues as well, but it's more important to offer her support in implementing some of the solutions best fit for her capabilities, expertise and pay grade. There's no need to take all the team issues upon herself of course, good professionals don't need babysitting, but being ready to help can go a long way.
She should also make sure that the team knows what she's doing day-to-day. Of course this does not mean that she needs to report everything to the team every day, but letting the team know regularly what she's focusing on, what problems are on her plate is usually appreciated.
Attend team events and team celebrations religiously. The team should always be aware that their lead is a human being, someone that can relate to their issues and is there for them in bad and good times alike.

I guess being a manager is not easy, and one of the toughest things about it is that sometimes there's very little difference between being great or bad at it.

Note: The images for this post were generated by DALL-E. No unicorns, pegasuses or any other beings were harmed in the process.

10 years later

Peter Aba — Tue, 05 Dec 2023 15:26:12 +0000

The second 10 years or so in a developer's life. Mine to be precise.

It touches on going from PHP to Go, but it's certainly a very personal post, which may not have a lot of instant take-aways. I hope some people will still enjoy it:
https://peteraba.com/blog/10-years-later/

3 recent posts on tech management I loved

Peter Aba — Tue, 06 Aug 2019 23:20:05 +0000

This post was first published on my blog.

Have you ever read a blog post so great, that you thought everyone should read it? I sure have, more than once, but I found that in most cases "everyone" just didn't care. Today however I decided to try something new. I'll cherry pick a few posts from the recent years by topic and share them as a single blog post. I'll throw in some of my own comments and act like I've actually done something creative today.

The article that pushed me to create this post was "The 3 Capacities of a Good Manager". It details 3 ways how bright engineers can end up as less than great managers. It also explains how to identify each way by symptoms. It describes how managers need to think about their roles. Finally, it provides managers with a simple framework to assess themselves. To some extent I felt like I was reading an excellent excerpt of a book, but somehow it felt complete at the same time. Matthew Werner did a great job here, I'll re-read this post many times for sure.
I really appreciated "The Engineer/Manager Pendulum" by mipsytipsy. In this post she argues that tech managers do their jobs best within the first 2 to 3 years after being removed from tech, and that people should generally go back and forth between engineering and management roles.
To be honest my motivations were slightly different, but I have become a tech lead for 3 years, only to become an individual contributor again. I grew to understand how I may have become a better leader / manager by not being one for a while. Of course, I understand that many in higher management may do well way after said 2 to 3 years. Still, chances are, they won't be doing a lot of tech at that point. I'd also argue that oftentimes any experienced manager could do a good job as CTO, except at times it's useful to actually understand the techies.
Finally, I loved Camille Fournier's "I hate manager READMEs". In this post she argues that manager READMEs might be well-intended, but they scream "I'm the boss here". They also sound like their authors are making weak excuses for their own weaknesses, quirks, and challenges. They can even suggest their readers that they're at fault if they don't know how to "handle" said managers properly.
Truth is, I also liked "12 “Manager READMEs” from Silicon Valley’s Top Tech Companies", but what I liked about them was the insight into how these people think. I never felt that it would be great to read such thing from my manager.

Okay, so that's 3 posts, therefore we're done. But since I just can't stop there, I'll add 3 more very briefly:

I just found out today that as for everything in tech, there's an awesome "awesome list" for management too. I'm especially stoked about the Meetings and Time Management page, which is a topic I definitely want to learn more about.
Switching from Engineering to Management is a good read for people who need to decide whether to make a career shift to management or not.
A while back I wrote about the dangers of detached management, which might be a nice addition to the first post: "The 3 Capacities of a Good Manager". Obviously, I'm biased though.

What are your favorites?

Test running Parcel with Elm 0.19 and Furtive (with Sass)

Peter Aba — Mon, 17 Sep 2018 12:26:45 +0000

Premise

So Ben started a discussion about Parcel the other day. I didn't participate in it, mainly because I've never even heard of Parcel before.

I did however open up the project website and it got me really interested for two reasons: First it seemed much simpler than webpack, second it promised to be much faster than webpack. Now my webpack experience is just slightly above what I'd describe as advanced beginner even though I already started a few dozen projects using it and watched many courses using it both on Youtube and Udemy. Most of the time however I just started with copying something that others crafted and adjusted it to my needs. I wouldn't go as far as to say that I had no idea what I was doing, but I certainly didn't master the tool.
I have copied webpack setups of some really knowledgeable people in the past, but I always felt that that the end result is somewhat clumsy and extremely slow, therefore I decided to give Parcel a shot. To make things more interesting, I decided to try to set it up with Elm 0.19 and Furtive

I literally just installed the tool this morning so I will not try to assess its performance in real-life projects but it sure feels much faster so far. What I will say however is that it was a breeze setting it up, even for me, even for such a weird setup. Let me drive you through:

Path #1: Quick and dirty way (<2 mins)

1. Clone my repo

git clone https://github.com/peteraba/elm0.19-furtive-parcel.git

2. Install the missing dependencies

yarn install

Path #2: DIY (~10 mins)

1. Create a new project directory

mkdir path/to/your/project
cd path/to/your/project

2. Initialize your project

yarn init -y

3. Add Furtive

For this project I decided to choose a tiny frontend framework called Furtive to keep things fast. I could have stayed with just including a minimized css from a CDN but I wanted to test Parcel so I decided to add Sass compilation instead:

yarn add node-sass
yarn add furtive

4. Add Elm support

UPDATE (2018-09-20):

This part has become much easier as 0.19 support is now added to parcel-plugin-elm, simply add it with yarn:

yarn add parcel-plugin-elm

Now this part was a bit tricky, because I wanted to use the latest Elm 0.19 and the main Elm plugin for Parcel is outdated. There is a pull request from Ben Hanna for 0.19 but it's not yet merged. Also, I'm not really a yarn expert, so I had to look up how to use his code instead of the official one. Okay, it only took about 2 minutes, but still..

So basically I downloaded Ben's code and extracted it to a directory called outdated and added it via yarn (yarn add file:./outdated/parcel-plugin-elm). This should remind me to use the main repo once the changes get merged.

5. Initialize your elm project

Parcel still doesn't know about Elm, so we should probably install it locally:

yarn add elm@^0.19.0-bugfix2

Then we can also initialize our Elm project:

yes | ./node_modules/.bin/elm init

Optional: global Elm install

In case you don't have Elm 0.19 installed but want to toy with it, please find the installation instructions in the Official Guide.

6. Create project files

`sass/main.scss`

$font-family: 'Lato', Helvetica, sans-serif;
$dark-gray: #222;
$text-color: $dark-gray;
$body-bg: #fafafa;

@import "node_modules/furtive/scss/all.scss";

.elm-container {
    margin: 5px 0;

    button, div {
        display: inline-block;
        margin: 2px;
    }
}

`src/Main.elm`:

import Browser
import Html exposing (Html, button, div, text)
import Html.Events exposing (onClick)
import Html.Attributes exposing (class)

main =
  Browser.sandbox { init = 0, update = update, view = view }

type Msg = Increment | Decrement

update msg model =
  case msg of
    Increment ->
      model + 1

    Decrement ->
      model - 1

view model =
  div [class "elm-container txt--center"]
    [ button [ onClick Decrement, class "btn btn--blue btn--s" ] [ text "-" ]
    , div [] [ text (String.fromInt model) ]
    , button [ onClick Increment, class "btn btn--green btn--s" ] [ text "+" ]
    ]

`index.html`:

<html>
    <head>
        <title>Hello, Parcel!</title>
        <script src="./index.js"></script>
    </head>
<body>
    <main></main>
</body>
</html>

`index.js`:

import './sass/main.scss'

if (module.hot) {
    module.hot.dispose(() => {
        window.location.reload();
    });
}

import('./src/Main.elm')
    .then(({ Elm }) => {
        var node = document.querySelector('main');
        Elm.Main.init({ node: node });
    });

Note: The if part in the middle is a workaround for a Parcel issue, might become obsolete soon.

End result

Okay, now we have everything in place, let's give it a go:

➤ parcel index.html
Server running at http://localhost:1234 
Success! Compiled 1 module.                                          
Success! Compiled 1 module.                                          
✨  Built in 2.23s.
^C

➤ parcel index.html
Server running at http://localhost:1234 
✨  Built in 724ms.
^C

Less than 3 seconds without cache, less than a second with cache, hot reload works as expected. What is more important however is that I didn't have to edit any configuration files.

Conclusion

I have to say I'm really impressed with Parcel so far. Its getting started guide is quite short, but it still allowed me to achieve what I wanted without getting confused or stuck even once. I think this might just be the beginning of a beautiful friendship...

Will PHP save your startup?

Peter Aba — Sun, 09 Sep 2018 15:34:33 +0000

About two months ago Alexander Katrompas wrote a post on medium titled Java will kill your startup. PHP will save it.. I already posted a short response as a comment there, but I thought it might be worthwhile to elaborate on that a little.

Again, if there's anything of which I can call myself an expert, that would probably be PHP. I don't really like PHP anymore, I don't write a lot of PHP anymore, but I do know it very well.

The arguments

Just to quickly recap, here are Alexander's arguments in a nutshell:

Many large-scale projects started off being written in PHP and over 80% of the top 10M web sites use PHP.
PHP programmers are more plentiful and cheaper than Java programmers. (web-only)
PHP has excellent performance and it continuously gets better and in-practice easily rivals compiled languages.
PHP application time to market is a fraction of Java EE applications.
PHP is not a “scripting” language (whatever that means), it’s a fully function, object oriented, web powerhouse.
PHP 7.x is a vast improvement over previous versions and 8.0 promises to surpass all expectations.
Frameworks are plentiful and powerful. The power, popularity, and dominance of Symfony and Laravel is undeniable.
WordPress (PHP driven) is the dominant CMS with almost 60% market share. The next top 5 CMSs, are all PHP driven.
PHP is simply made for the web. No extra servers, processors, hacks, tricks needed. It is literally one with your web server.
Most dominant open source e-commerce systems are all written in PHP. (WooCommerce, Magento, OpenCart, PrestaShop, ZenCart, Drupal, Joomla, OsCommerce, and on, and on, and on…

My comments on the arguments

As the title and the above list shows, Alexander was comparing PHP to Java EE. Now I have very little knowledge on the latter, but I can tell you that for most startups PHP is no longer the best choice.

Just to clarify, there are a few points that I strongly disagree with. In my opinion:

PHP is a scripting language. It does have decent OO features, but that has nothing to do with it being a scripting language. What it does affect is first that not all of your code will be loaded into memory when a request is served (good), that all of your errors will be runtime errors (bad) and of course that your code will be interpreted on an as-needed basis instead of having it all compiled to byte code or some intermediate language. Sidenote: Alexander mentions "function, .. oriented" there as well, but I'm hoping that was nothing more then some copy-paste mistake.
PHP 7 is a step in the right direction, but it wasn't brave enough to really clean up the API and I doubt PHP 8 will be.
PHP is made for the web but there are extra servers, processors, hacks and tricks needed. It is absolutely not one with your web server and if you've been close enough to operational teams of big PHP projects you'll know how much a pain in the ass it can be. Not that it's a PHP-specific thing but just to get things straight. I'm guessing that Alexander was referring to the PHP apache extension, but that's not something I've seen running live in the last 10 years and probably you shouldn't either...
PHP is fast enough for serving as the backend of an API. If you need true performance for complicated stuff (databases, crypto-mining, etc.) then it probably isn't.

Still, with all these corrections I think the problem lies in what's missing from the list, not what's in there.

First of all if your startup is about selling flip-flops, then by all means go ahead, install Magento and off you go. You'll still be able to ditch it for something more flexible when you actually start to make money and feel the pain of running an over-engineered, yet rigid system. (wink-wink Zalando).

If however you want to build something that's a true Zero-to-One type startup, you need a system that gives you agility:

Fast to learn.
Fast to prototype in.
Straight-forward to harden.
Enables fast and safe refactoring.

Plus I'd consider these things as nice-to-haves for startups but absolutely must-haves for mature companies:

Maintainable
Secure

And finally two nice-to-haves for the most successful startups, the corporations:

Exciting
Trustworthy

Fast to prototype in

Now I have the feeling that Alexander focused way too much on prototyping for which PHP is quite good indeed. Not the best, but certainly decent, probably better than the famously verbose Java is.

Just to clarify, Java is famous for being verbose but I wouldn't call PHP concise either. It's not a really a criticism, simply a statement. (In comparison Python and Ruby code tend to be significantly shorter and easier to read than equivalent PHP code.)

Straight-forward to harden

When it comes to hardening, your only real choice is adding more tests because the type system is just very hard to rely on. You can harden your own code ensuring that you use types everywhere (you'll need at least 7.1 to really do that) and marking each of your files to be type checked strictly, but it's a hassle, error prone and it's tough to get all your dependencies to provide similar safety. Also, if you end up using any of the popular frameworks (Symfony, Laravel, Zend, etc) you're out of luck, as they all -support 5.x still- (Correction: they require PHP 7 lately, but don't enforce strict type checking). And the truth is that 99.9% of all PHP teams will decide to use these tools because of familiarity and the size of their ecosystems.

If the choices only came down to PHP and Java, I'm sure Java would easily win here. It still suffers from the billion dollar mistake, but at least the compiler will yell at you if you change your API in one file and forgot to update it in another. In PHP you'll just hope it will be caught in a test or during code review, given you have those. (Spoiler alert! In most start-ups you don't, because you know, they take time and therefore money)

Enables fast and safe refactoring

When it comes to fast and safe refactoring there's hardly anything worse than PHP, so Java would win easily, mainly still due to its type safety and the compiler being able to check your whole application by default. Again Java is probably far from the best choice as some functional and functional-inspired languages will go further in this regard, but I think it should already be decent.

Fast to learn

This is the final point in the must-have section for startups, but it can be very important in some cases. Alexander avoids this problem by saying it's cheaper to hire PHP devs and Java devs. While it's probably true, the difference likely not to be comparable to choosing the wrong language and having to rewrite everything later. Yes, as a startup you might want to cut that 20% on IT salary expenses, but you should understand that you're playing with fire. I myself would rather risk running out of money 2-10% earlier then risking years of suffering of wrong choices early on.

So if we agree with the premise that you can always bring in people already familiar with your stack then Alexander was probably right, but the difference shouldn't make or brake your startup.

I'd however argue that I'd prefer working with a language that less people know but is very easy to learn. That way you can get the best domain experts bring tremendous value and you never risk of running out of local talents because any engineer you'd get would be able to get productive in a few weeks.

Now this is where I'm fairly sure both PHP and Java suck, and they actually suck big time. Both these languages try to satisfy everyone, putting all sorts of features into the language and both of these have huge-huge ecosystems which take years and perhaps decades to fully oversee and takes tons and tons of reading to make sure you understand best practices and things to avoid. Not to mention how much terrible advice must be out there for both of these languages... Still, as a beginner searching for good answers must be a nightmare both for Java and PHP.

In contrast many newer languages try to keep things straight forward. Go is the most obvious example here but Elm and Rust can also simplify many things even if they bring in some concepts which are harder to grasp at first.

Ecosystems of these new languages are also cleaner and in the case of Go most things you'll use are in the standard library, tested at Google-scale and quality that you can easily bet your company on. The community also lives and breaths the Unix-philosophy, which means popular tools tend to do one thing and do that well. It's definitely not true for PHP and I doubt it would be for Java EE, although I can't really judge that.

Note: I hinted it before, but to be clear: if you can utilise one of the many open source PHP applications out there then it can be a much larger save than just 2-10% and it might make a lot of sense. Most obvious example is e-commerce, but there are some others as well. In case of e-commerce, you should either just use an existing ready-made service, some marketplace or build on top of Magento, Thelia or Sylius. Prestashop might have some use cases too, but if anyone recommended me WooCommerce, OpenCart, ZenCart, Drupal, Joomla or OsCommerce for e-commerce, I'd run away and I'd run far.

Maintainable

I spent most of my professional carrier working on huge (>1.000.000 lines) legacy applications trying to clean up the mess my predecessors left behind themselves. Most of the pain came from over-engineered OOP monstrosities. Because of that, I truly appreciate the simplicity of Go and Rust and for me both PHP and Java would score really badly.

I also enjoy the extra safety functional languages can provide but they can affect how fast a language is to learn, so you'd have to take that into account while assessing them for "fast to learn" and "excitement".

Secure

This is a point where I really lack the knowledge to properly assess Java, but PHP does have a pretty bad track record. I have the feeling that Java would fair better, but I'd rather skip this topic saying that there are better languages out there than PHP. In fact, I believe PHP is among the worst.

Exciting

Now this is certainly not important for all startups but if you are thinking about something technologically challenging, then you should try to appeal to the best minds available in your area. These people will be able to learn a new language, but they won't learn just any language you throw at them. Not because they can't, but because they don't want to.

Unfortunately PHP is among the least respected languages out there and this means that the brightest software engineers probably never learned PHP and probably aren't willing to learn it.

Java is slightly better off here because anyone who got a computer science degree in the last 2 decades have learnt Java at some point and many even stuck with or sticked to it. On the other hand it's also not the most popular language to learn for people outside of the Java community these days.

On the upside however there are other JVM languages with current momentum (Scala and Kotlin mostly) which claim to provide easy access to anything written in Java, so that could be a safe way forward I think.

I will admit that this is not a topic I can't fully assess, but I have the feeling Java still wins here.

Trustworthy

This is an easy knockout for Java EE. If you want to go public or sell your product to fortune 500s you'll want Microsoft (C#), SAP and Java EE on your portfolio. And that's pretty much a complete list as far as I know.

Conclusions

So I had PHP winning one point easily and another one potentially. There are many points where I admitted I don't necessarily have the Java-knowledge to assess both but in these cases PHP scored pretty bad, forcing me to believe that Java is the better technology to start a green-field project.

This does not mean that PHP will kill your startup and Java will save it. What this post meant to say is that you should understand the consequences of your choices, understand the risks you make and choose whatever will make you sleep better.

If cutting 2-10% of IT expense is all you want then PHP (or NodeJs) is reasonable.
If you need to have your blog or e-commerce site available ASAP then PHP is probably your best choice, but you should make a good reason not to use an existing service instead.
If you want to sell your product to Fortune 500 companies then Java is probably still the keyword to score a deal, although other JVM or .NET languages might also make sense.
If ensuring you won't find yourself in a situation where you have to rewrite everything then use a statically typed, compiled language. I'd recommend Go but I hear Kotlin might be a reasonable choice as well.
If you don't need first class support by major cloud providers, but runtime errors can kill your company then consider Rust or Haskell.

Finally, if you really wanted a simple answer to the question "will PHP save your startup?", I'd have to say no. Not unless you're building something on top of an existing PHP application. Will PHP kill your startup though? Probably not, but it's likely to make it less agile than it could be.

The danger of detached management

Peter Aba — Sat, 28 Jul 2018 09:22:01 +0000

This post first appeared on my blog.

Obviously none of the following have I ever experienced personally, it's more of a thought experience I suppose.

So let's say you have a software feature team made up of a handful of focused and experienced professionals and perhaps a few juniors just for good measure. Let's also imagine that this is true for both the engineers and the product managers and they together manage to implement a very fruitful culture where things to deliver and their priorities are always clear. Things also get delivered more or less on time and technical dept is also kept under control. Sounds great so far, right?

To color that picture a bit further let's also imagine that this imaginary team has some process in place to improve their internal processes and discuss pressing issues. For example they might meet regularly for Kaizen meetings to keep things generally improving.

It's obvious that she lifts a lot of weight off the teams back, practically enabling them to focus on the product and engineering tasks. I suppose this should still sound great, there's hardly anything to boost team performance more than cutting out distractions. The problems start when she decides not to have one-on-one's with her team members and that since she's not part of the day-to-day work of the team attending standups or the Kaizen might be optional for her. This however can render her practically detached from her team.

These can effect the team in a few ways.

Hard to get help. Perhaps least importantly if and when there is a problem the team can not solve itself, it is harder to get the lead to weigh in or help because first she's not used to weighing in on team issues and second she might lack some context which is not always easy to properly explain.
Awkward team activities. Team members may also feel somewhat awkward or even anxious around a detached lead as she may be seen as some sort of an outsider without sufficient amount of regular interaction. As consequence this may also poison team activities such as team events in some cases. This is more of a problem for introvert team members probably, but still worth mentioning.
Lack of trust. Lack of touch can also cause a lack of transparency and team members might start wondering what their lead is doing most of her time and whether she has enough insight into the teams' work to be able to properly represent them in long term planning sessions with other managers.
Understanding team performance. For example let's say the OKR says product X will be delivered by the end of the quarter but then some urgent request comes up that pushes the team to deliver product Y first. Or perhaps there's also a dependency on team Z to deliver product X and they're late. Either way at the end of the business quarter product X is not delivered, therefore a detached manager may think that the overall performance of our imaginary team is less than great. Technical improvements throughout the quarter might also easily go unnoticed of course.
Understanding individual performance. Team members might be judged on weird measures like being typically vocal or less vocal during selected meetings attended by the lead used for example. Imagine that being used as a deciding factor for your relative performance compared to the team average. This can of course further lead to team members getting unfair and unhelpful promotion feedback which will inevitably force valuable employees to seek their promotion in the form of a new position at a different company.
Creating legacy systems. Possibly the more important consequence of such unfair feedback is that people who don't quit will typically adjust. When technical greatness is not appreciated, people will simply focus on product delivery and quality will naturally decline. This on the other hand is the perfect recipe for creating legacy systems that no one wants to touch anymore. When this happens, the lead will have her job failed as hard as possible, no matter how great a job she does doing her day-to-day job.

I imagine most of the above would apply to any delivery team, in or outside of IT, however with software feature teams there's an extra risk: Whether the product delivered is of poor or great quality can be very hard to tell. If the live system is broken every second day, that's a clear sign of course, or in case the UI is not usable it's easy to assume that the code is one big pile of ... spagetthi. However the complexity of even the simplest software system is still more complex than most other products in life and this means even software that does a decent job on the surface might be less than pleasant to work on as an engineer. (That's what we typically call a legacy application.)

As I see it, a manager has two main choices to gain a better understanding of the overall quality of the product her team produces.

She can either make sure to be involved in development, check the code produced for key features, be part of standups and main design decisions religiously. This is absolutely doable, I've seen it done multiple times, but definitely takes a lot of time. Problem is that this might render her partially unavailable for important manager discussions and she might also easily become a blocker for the team when she's less available.
She can also choose to invest instead into understanding how her team members work as a team, join in some of the design decisions and observe how things get handled. Plus she'd still need to make sure to have a personal connection with her team to get better insights of potential problems. If things don't go as they should, she would still have option #1 to try, but if everything is okay, she'd have more time for other important tasks.

I guess being a manager is not easy and one of the toughest thing about it is that sometimes there's very little difference between being great or bad at it.

Polyglot Tinkering - Moving to Firefox with Python

Peter Aba — Sun, 13 May 2018 17:20:16 +0000

This post first appeared on my blog.

Firefox?

I started working as a web developer during the spring of 2002, less than a year after IE6 came out. For those who have ever heard about IE6 it should be obvious that this means that I spent a significant amount of my life working around the various quirks of IE and of course that I was at one point in my life a huge Firefox fan. Firefox was amazing at the time but unfortunately it became slower and slower with each iteration and by the time Google Chrome came around most web developers were ready for something much faster. I used a fair number of browsers since but I always found myself going back to Chrome for one reason or another and so did the majority of my colleagues.

I was a bit sceptical but also excited about Rust and Servo and I tried out the new Firefox as soon as it came out as stable. I loved its speed and many of its features but I had two major issues with it on Linux:

For some reason I had no sound after a few days and it never came back.
LastPass sucked as the copy password feature seemed broken.

So I again went back to Chrome even though I prefer to de-Googlize myself as much as I can.

LastPass?

Okay, so let's fast-forward a few months until I read Calling all web developers: here's why you should be using Firefox and decided it was time to give Firefox another shot. This time sound was working just fine but LastPass still had issues copying my password. When I opened a page with a password stored the input fields were filled out properly, but I couldn't easily search for a stored password and copy it.

This is a huge problem for me.

I hope I don't even have to mention how important password managers are in general but for me having autofill is just not enough. Period. I store tons of passwords and notes which I often have to copy to access various things and opening a detail page in my LastPass Vault is just way too slow to be a viable option.

So at this point I decided to create my first support ticket with LastPass. Their response was fast, brief and quite disappointing. To quote the relevant bits:

I am sorry to inform you that Firefox browser on Linux does not support binary feature.
Binary feature is required for copy username and copy password.

Well, I guess this would just mean back to Chrome to most people, but I instead decided to come up with a tool to solve my problem. I did not mean to fix everyone's problem nor was I thinking of some fancy project on Github with stars and all. I wanted something quick and dirty, something that's fun for me to write and solves my problem in a way that I'm no longer blocked from using Firefox as my primary browser.

Clarifying the project

Here were my requirements:

I need to be able to access my notes and passwords for use cases other then logging into websites. (For that autofill works fine)
The solution must be at least as fast as using the LastPass Chrome Extension:
1. Realise I need to enter a password to get my work done
2. Open / Go to Chrome
3. Open LastPass browser extension
4. Search for the record I'm interested in
5. Right click on the entry I need
6. Copy note or password

My first idea was to create a small desktop application which sits in my system tray and lets me look up passwords as needed. Then I figured that what I'd really want is to have a keyboard shortcut to open this application which would allow me to search instantly. Finally I realised that I'll start with a CLI app and I'll think about how to start it up once it works in a terminal.

LastPass CLI

This thought process took about 2-5 minutes and in the meanwhile I found lastpass-cli which looked like something I could use, except that it required multiple command calls to achive what I wanted.

I tested out how to solve my problem using my shell (Bash / Zsh):

lpass login
lpass ls | grep "my-favorite-server"
select the id of the server I want to access (using a mouse)
lpass show "id-of-my-favorite-server"
copy the note or password to clipboard (using a mouse)

my-favorite-server [id: 1112223334445556667]
Username: root
Password: my-super-safe-password
Hostname: 123.234.432.321:12345
NoteType: Server

Okay, so it seemed like I can really kind of do what I need by using lpass, grep and xclip but I'll also need to be able to select one of the results of the search if there's more than one. Now I happen to be a reasonably experienced terminal user and bash coder for someone who's never been paid to be a sysadmin, but to be honest I felt disgusted by just thinking of the amount of script needed for this tool, mostly because manipulating strings is cumbersome in Bash. It is much nicer in zsh but most of the time I need to stick to bash and therefore my zsh-foo is quite basic.

Finding a tool that fits

Okay, so if not bash then what? Well, this is such a simple task that could be done in almost any programming language I'm aware of (Elm being the exception) but at first I only really thought about the ones I use every day to keep things simple. However I didn't happen to like them for this task:

PHP feels bloated for wrapping CLI calls plus it's not installed on all my computers
Go also feels a bit clumsy for wrapping CLI calls because of it's type safety.
JavaScript is not a contender for me because I don't like Node.

Well, out of the above choices I'd choose bash without hesitation in this case but then I remembered that sysadmins tend to love Python. I never used Python heavily but I was sure that I'd be doing less answer-hunting on stack-overflow than for Bash and that I'd like the end result more and that it is a better fit for the task than my primary languages.

Hacking is fun

It took me about an hour to hack together what I needed. I have to admit the resulting code is not something I'll ever be proud of:

The script only works on Linux systems as it is
I even made a decision during development that I won't create functions, just to keep things simple. (Sorry, not sorry.)
I'm sure one could have achieved what I did in less than 20 minutes both with Python or Bash / Zsh.

Using Python however proved to be a blast and I think the end result is readable even if it lacks real craftsmanship. Hell, hacking is still fun!

One of the coolest things about being a programmer is that you get to solve many of your own problems with relative ease. It's especially true if you take the time to wander to programming problems, principles and languages which you don't use every day. Python certainly rocks although I'll probably never work on anything serious using it.

Result

If this is an itch you share with me, feel free to use the script I wrote: https://github.com/peteraba/dotfiles/blob/master/scripts/lps

To make it really efficient I recommend using a Quake-like terminal like Guake so that it's always one key-stroke away.

With this script my routine to retrieve a random password looks like this:

Realise I need to enter a password to get my work done
Hit F12 to open Guake (unless I'm already in a terminal)
Type lps my-favorite-server
Select one of the many results by typing a number and hit Enter (unless there's only one result)

At this point the script tells me that the note or password is already copied to my clipboard. This is way faster than using the Chrome Extension saving me at least 1-2 minutes every day. More importantly I can now fully embrace any new browser, the lack of a LastPass extension shouldn't hold me back ever again.

FP public code review (#1)

Peter Aba — Sat, 13 Jan 2018 17:40:28 +0000

Imagine the following: You're a software engineer in a small team of an amazing but small company. One day your lead comes up to you saying that the company is looking for more engineers to hire but the person in charge of the tech part of the process had to leave in a hurry for her home country in the middle of the process. Unfortunately she won't be available in the foreseeable future.

Originally there were tons of applications but HR and some juniors already filtered out the most obviously weak ones. There's still a handful of applications for you to sort out however. All the applicants solved the same set of problems using some online tool and your job is to check all remaining solutions for one of the problems.

Since there's only time to invite a limited amount of applicants for an on-site interview, they'd like to have your expert opinion about how well each applicant performed. There will be other factors for sending out the invitation(s) so they need more from you than just selecting the best solution. It would be best if you could describe what each solution does well and how they could be improved, but please make sure to score each from 1 to 10, 10 being a perfect solution.

All solutions are in F#, but the company is looking for good programmers, not necessarily F# experts. It's okay if they aren't using F#-specific shortcuts although that's okay too. You need to review their solutions for the following problem: (copy-paste from the Sieve exercism.io problem)

Sieve problem

Use the Sieve of Eratosthenes to find all the primes from 2 up to a given
number.

The Sieve of Eratosthenes is a simple, ancient algorithm for finding all
prime numbers up to any given limit. It does so by iteratively marking as
composite (i.e. not prime) the multiples of each prime,
starting with the multiples of 2.

Create your range, starting at two and continuing up to and including the given limit. (i.e. [2, limit])

The algorithm consists of repeating the following over and over:

take the next available unmarked number in your list (it is prime)
mark all the multiples of that number (they are not prime)

Repeat until you have processed each number in your range.

When the algorithm terminates, all the numbers in the list that have not
been marked are prime.

The Wikipedia article has a useful graphic that explains the algorithm:
https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes

Notice that this is a very specific algorithm, and the tests don't check
that you've implemented the algorithm, only that you've come up with the
correct list of primes.

Source

Sieve of Eratosthenes at Wikipedia http://en.wikipedia.org/wiki/Sieve_of_Eratosthenes

Solutions

Here are the solutions you need to rate, review and report back to management and HR. Use the a comment section of this post for communicating with them:

Solution #1

let primesUpTo2 limit =
    let rec mark st acc prime limit =
        let acc' = acc + prime
        match acc' > limit with
        | true -> st
        | false -> mark (Set.add acc' st) acc' prime limit

    let rec iterate st list limit =
        match list with
        | [] -> st
        | x::tail ->
            match Set.contains x st with
            | true -> iterate st tail limit
            | false ->
                let st' = mark st x x limit
                iterate st' tail limit

    let list = [2..limit]
    let nonPrimes = iterate Set.empty list limit
    (Set.ofList list) - nonPrimes |> Set.toList

Solution #2

let primesUpTo3 n =
    let sieveStep n ((primes, composites) as acc) i =
        if Set.contains i composites then acc
        else (i :: primes, {i..i..n} |> Set.ofSeq |> Set.union composites)

    {2..n}
    |> Seq.fold (sieveStep n) ([], Set.empty)
    |> fst
    |> Seq.rev

Solution #3

let primesUpTo1 limit =
    let sq = (limit |> float |> (fun n -> n ** 0.5) |> int )

    let filterMultiples possiblePrimes prime =
        if prime > sq then possiblePrimes
        else possiblePrimes |> List.filter (fun x -> x <= prime || x % prime <> 0)

    let possiblePrimes = [ 2 .. limit ]

    List.fold filterMultiples possiblePrimes possiblePrimes

Solution #4

let primesUpTo4  n =
    let isMultiple factor x = x % factor = 0
    let rec seiveNextPrime primes = function
        | prime :: tail -> seiveNextPrime (prime :: primes) (List.filter (isMultiple prime >> not) tail)
        | [] -> List.rev primes
    seiveNextPrime [] [2..n]

Solution #5

type Candidate  =
    | Unmarked of int
    | Marked of int

let primesUpTo5 limit =
    let mark prime range =
        range 
        |> List.map (
            function
            | Unmarked i when i % prime = 0 -> Marked i
            | c -> c)

    let rec sieve marked =
        function
        | [] -> marked |> Seq.rev
        | ((Unmarked p) as pp) :: tail -> sieve (pp :: marked) (mark p tail)
        | c :: tail -> sieve (c :: marked) tail

    [2..limit]
    |> List.map Unmarked
    |> sieve []
    |> Seq.map (
        function
        | Unmarked i -> i
        | _ -> 0)
    |> Seq.filter ((<) 1)

If you like this discussion, let me know and there might be more coming.

Go is my gateway drug

Peter Aba — Mon, 08 Jan 2018 12:01:58 +0000

This post first appeared on my blog.

I've been a long time PHP / JavaScript developer by 2013 when I first started toying with Go. It's been almost 5 years by now and I've been an advocate of the language ever since. I was one of the many programmers who tried it out for the concurency primitives but stayed for it's simplicity. It was with Go that I realised how much nicer life is without inheritance and the rest of the OOP shenenigans. On the other hand Go also gave me a push to experiment with even more languages. It turned out to be my gateway drug to learning programing languages.

Of course, I played with some languages like Java, Python or Ruby before but honestly they didn't provide me anything that would be that much more than I had before. I was not interested in writing games, desktop or mobile apps at the time, I was happy as webdeveloper. To me Java felt too clumsy, Ruby felt too much magic and Python felt lacking the momentum at the time. (Not to mention the 2.x vs 3.x confusion.) Learning either of these languages felt too much work for the potential gain. With Go it was different, practically a love at first sight. It was so easy to learn and promised (and fulfilled) so much that I couldn't even stop learning more. Once I mastered it though, I realized that my old OOP languages feel verbose and my dynamically typed languages feel fragile. I was however feeling that Python was nicer to read than Go and this made me looking at further languages, mostly new ones like Rust and Elixir.

There are a few ways to try out new languages and I usually prefer doing a small project in them even if I never actually finish those projects. This past two weeks however I went back to an old favorite: exercism.io. What's really nice about this service is that you can check how others solved a particular problem and with a bit of extra effort it's also possible to find or construct a "perfect" solution.

To showcase what I mean I'll add a few solutions for a simple problem called the Hamming problem throughout the exercism.io. The problem is simply finding the "distance" between two strings meaning the number of characters being different.

PHP

Here's my PHP solution from 2015:

<?php

function distance($a, $b)
{
    if (strlen($a) != strlen($b)) {
        throw new \InvalidArgumentException('DNA strands must be of equal length.');
    }

    $aSplit = str_split($a);
    $bSplit = str_split($b);

    $diff = array_diff_assoc($aSplit, $bSplit);

    return count($diff);
}

It's actually quite simple, there's just one if for checking the string lengths. On the other hand there are a few strange things about PHP already showing:

Notice how str_split has a '_' character to separate the parts but strlen is written as one word? Typical PHP...
Notice that array_diff_assoc is a rather specific function. It shows me that there is a very large standard library to learn.
Throwing an exception is okay. If you're a consumer of this function, you better catch the exception being thrown here.
The lack of types mean you can always call this function with whatever values you want from null to any type of objects, up to you. (Yes, this can be optionally fixed in PHP 7.0+, kind of.)

Note 1.

Hopefully no one would try to get everything done in one line, because it can seriously hurt anyone looking at it:

<?php

function distance($a, $b)
{
    if (strlen($a) != strlen($b)) {
        throw new \InvalidArgumentException('DNA strands must be of equal length.');
    }

    return count(array_diff_assoc(str_split($a), str_split($b)));
}

Note 2.

One could also write the following using PHP 7 making some of the issues go away. Typing is still optional though therefore there are still no general guarantees. Given that it's a scripting language, braking changes aren't necessary obvious before you deploy them unless your test suite has you covered.

<?php

/**
 * @throws \InvalidArgumentException
 */
function distance(string $a, string $b): string
{
    if (strlen($a) != strlen($b)) {
        throw new \InvalidArgumentException('DNA strands must be of equal length.');
    }

    $aSplit = str_split($a);
    $bSplit = str_split($b);

    $diff = array_diff_assoc($aSplit, $bSplit);

    return count($diff);
}

Go

My Go solution from 2017:

package hamming

import "errors"

const testVersion = 6

func Distance(a, b string) (int, error) {
    if len(a) != len(b) {
        return -1, errors.New("Lengths of the provided strings are not equal.")
    }

    aBytes := []byte(a)
    bBytes := []byte(b)

    dist := 0
    for i, ch := range aBytes {
        ch2 := bBytes[i]
        if ch != ch2 {
            dist += 1
        }
    }

    return dist, nil
}

OK, what's the takeaway here?

This is considerably longer and more complex than the PHP solution.
On the other hand it requires much less prior knowledge from the user to understand, we don't even use the standard library. (To be fair it could also be avoided in PHP)
There's no way this solution could be written on one line without breaking readability completely.
Notice how the strong typing makes it impossible to call this method with weird data and how predictable the returned data is, except that error can also be a nil.
Notice how errors handled by just forcebly returning an error type, "never" throwing something unexpected. (In reality there is a panic which can be raised, but it's usage is different from your typical exceptions)
Make sure you understand that the error can be nil. Warning: There will be dragons!
It might be strange that the function starts with a capital letter whereas the other identifiers start with a smaller case. This makes the code public / exported in Go.

Note: I tried to find a more functional or considerably simpler solution but I didn't find any.

UPDATE: Benjamin Cable pointed out a few issues with the above code and suggested a better alternative. For issues described check out the comment section, the code is as follows:

func distance(a, b []byte) (dist int, err error) {
    if len(a) != len(b) {
        return dist, errors.New("length of provided strings is not equal")
    }

    for i := 0; i < len(a); i++ {
        if a[i] != b[i] {
            dist++
        }
    }

    return dist, nil
}

Python

My Python solution again from 2015:

"""Python distance exercise solution"""

def distance(text_one, text_two):
    """Calculate distance between two strings"""
    count = 0

    for (char1, char2) in zip(text_one, text_two):
        if char1 != char2:
            count += 1

    return count

Takeaway:

The cyclomatic complexity is a bit larger here than with PHP, even without the error checking, but I do find it easier to read.
Python's support for tuples and the zip function makes it kind of functional-like, although the for loop isn't all that usual in FP.
There's nothing preventing us from calling this function with strange data.
There's little we can expect from this function to be returned. If we change the return type to a string, the callers won't know until they get a runtime error.
We are using the standard library here but zip feels much less esoteric than array_diff_assoc was for PHP.

Note: My Python is roughly on advanced beginner level, Christoph Schindler appears to be more experienced, his solution reads even more functional-like:

def distance(sequence, other):
    if len(sequence) != len(other):
        raise ValueError('Sequences must be of same length.')

    return sum(1 for a, b in zip(sequence, other) if a!=b)

Additional takeaway:

By raising a value error we can cause even more havoc on the caller's side.

F-sharp

and finally here's the same thing I wrote in F# this week having about 2 days worth of experience:

module Hamming

let distance (strand1: string) (strand2: string): int option =
    match strand1.Length, strand2.Length with
    | x, y when x = y ->
        let seq1, seq2 = (List.ofSeq strand1), (List.ofSeq strand2)
        Some(List.fold2 (fun acc a b -> if a = b then acc; else acc + 1) 0 seq1 seq2)
    | _, _ -> None

What can we take away here?

It is slightly longer than the Python solution.
You may find the match syntax strange but you can think of it as an if on steroid for now.
There's no way you could call this function with wrong types.
The response is even more obvious than Go's is as the null part is not a surprise here, it's expressed by the option type annotation.
We are also using the standard library here but, much like zip, List.fold2 and List.ofSeq also feel much less esoteric than array_diff_assoc in the PHP solution.

It is not obvious from the above example but explicit type definitions are optional in F# unless the compiler tells you that you should provide them. Types however aren't optional like they are in PHP and partially in Python and since it's a compiled language there's much less space for mistakes too. Not having to deal with types in the first place can make coding feek much more like a scripting language when compared to C# for example. I only wish the compiler was faster, much faster if possible. (Go's compiler feels about 100x faster.)

UPDATE: As I mentioned above I just started to get deeper into FP languages and F#, here's a better solution from the comments:

let distance s1 s2 = 
  if String.length s1 <> String.length s2 then None
  else
    Seq.zip s1 s2
    |> Seq.sumBy (fun (c1, c2) -> if c1 <> c2 then 1 else 0)
    |> Some

It's hard to argue that this is a very elegant solution.

Conclusions

I guess it's no surprise that I find the F# solution the best here, but of course I do not mean to say that F# is the best language out of the four. I don't even think it's fair to say such a thing in general. I also don't think that this example proves in any way that FP is better than OOP. Obviously these examples provide no good insight into how hard these languages are to learn, how usable they are in the wild and many other important aspect of the languages. They do prove however, at least to me, that it's worth learning other languages as not all languages are equal.

Also exercism.io is an awesome dealer.

DEV Community: Peter Aba

Revised: The danger of detached management

Preface

Scenario - The good parts

Impact - The bad parts

1. Hard to get help

2. Awkward team activities

3. Lack of trust

4. Understanding team performance

5. Understanding individual performance

6. Creating legacy systems

Solutions

10 years later

3 recent posts on tech management I loved

Test running Parcel with Elm 0.19 and Furtive (with Sass)

Premise

Path #1: Quick and dirty way (<2 mins)

1. Clone my repo

2. Install the missing dependencies

Path #2: DIY (~10 mins)

1. Create a new project directory

2. Initialize your project

3. Add Furtive

4. Add Elm support

5. Initialize your elm project

Optional: global Elm install

6. Create project files

sass/main.scss

src/Main.elm:

index.html:

index.js:

End result

Conclusion

Will PHP save your startup?

The arguments

My comments on the arguments

Fast to prototype in

Straight-forward to harden

Enables fast and safe refactoring

Fast to learn

Maintainable

Secure

Exciting

Trustworthy

Conclusions

The danger of detached management

Polyglot Tinkering - Moving to Firefox with Python

Firefox?

LastPass?

Clarifying the project

LastPass CLI

Finding a tool that fits

Hacking is fun

Result

FP public code review (#1)

Sieve problem

Source

Solutions

Solution #1

Solution #2

Solution #3

Solution #4

Solution #5

Go is my gateway drug

PHP

Note 1.

Note 2.

Go

Python

F-sharp

Conclusions

`sass/main.scss`

`src/Main.elm`:

`index.html`:

`index.js`: