So much Hello, World!

Today I listened in on a few tech screens with some Java developers. The experience made me want to crack open Exercism. Exercism is an amazing platform to write some code and get some feedback.

So here’s a collection of various people’s ways to say Hello World from the first Java exercise.

Here’s another one:

Ok, that one was clearly wrong. Here’s another one:

And another one, which I rather like for its thoughtfulness:

Another one:

And this:

And this one with some dependencies:

Yet another:

Those are just some examples from the past few days. Some I like, some I don’t; some are more efficient, some are not. My only point in this post is to just highlight that, even in a simple hello, world example, there are many different approaches.

Bedrock Characteristics of an Effective Tech Lead

In the Truth About Leadership, James M. Kouzes and Barry Z. Posner offer no-nonsense, trend-free guidance that may help us nail down the bedrock characteristics for an effective tech lead. Kouzes and Posner surveyed 10,000+ people worldwide to uncover the key characteristics defining a good leader, traits that often come to mind when we think about leadership —  honesty, competence, fairness, supportiveness, courage, maturity, and so on.

Surprisingly, respondents consistently selected four characteristics far more often than the others: honesty (85%), forward looking (70%), enthusiasm (69%), and competence (64%).

Interestingly, intelligence, at only 42%, didn’t make the cut. We’re in the smart business, so we often try to lead with logic and intelligence. That’s clearly a mistake (and more than this survey prove it). So let’s dive deeper into what the authors think actually matters.

Basic Credibility Tech Leadership Traits: Honesty, Enthusiasm, Competence

Three of the traits work together to make us “credible” tech leads with the people on the team: honesty, enthusiasm, and competence. To drill in a bit, honesty is what you’d expect: telling the truth, having clear standards, and integrity. Enthusiasm (the authors actually called it “inspiring”) is also what you’d expect. “Energy signals commitment,” say the authors; we don’t follow those who aren’t committed.

Competence deserves some special discussion. The authors defined competence as the ability to get results from others. That feels like circular logic to me, and besides, in a dynamic field like software engineering, where there are too many posers, you need to possess a basic level of competence before people will follow you as a tech lead.

That’s not to see you have to be the mythical 10x engineer (in fact, being 10x might work against you), but need to spend some time in the trenches, enough to know whether the task you’re asking engineers to complete is trivial or Herculean and enough personal experience to know when you’re losing their interest and excitement.

The Tech Leadership Trait: A Forward Looking Vision

The key credibility traits (honesty, enthusiasm, and competence) are what we hope every software engineer on the team possess, right? So where’s the “leadership” piece? It turns out the trait that differentiates you as a tech lead is your ability to be forward looking.

Forward looking means more than just being able to see into the next sprint or around the next technical edge case. Being forward looking means you have a clear, long-term vision of the future of the product and team. You, with clarity, can envision how your team’s product, workflow, codebase, or culture could be better not just tomorrow but in the months to come. Clarity is key because a vague wish for something like “engineers doing more TDD” or “product owners writing better stories with better acceptance criteria” isn’t clear enough for the team to truly rally around, other than to complain during lunch at Chipotle.

Additionally, true tech leaders have an ability to map their vision to their team member’s hopes, goals, skills, and immediate aspirations. It’s easy to be a whiteboard visionary; it’s a whole other level to be able to clearly connect your vision to the day to day hopes, goals, and general work patterns of your team.

A word of caution. While your forward thinking vision is the big differentiator that separates you from being a highly competent team member, you can’t lose sight of the core credibility traits. No matter how compelling your vision, nobody on your engineering team will follow you if you aren’t credible. If you focus too much on “vision” and lose your grounding in credibility, you’re going to lose a big part of what makes you effective in the first place.

Be credible first, forward thinking second.

You’re Probably Demonstrating Strong Tech Lead Traits Already

I want to propose to you that, if you’ve made it this far into this post, you’re probably already modeling some or all of the key traits we just talked about. For example, you’re probably already honest in the sense that you have high standards for performance and integrity about the quality of your code and the results you and your team are producing. Odds are that you’re competent and enthusiastic about the future for your team and what you’re doing together.

Not only are you modeling many (or all) of them now, you probably notice that the traits Kouzes and Posner identified come more naturally to you than less valuable traits requiring stronger people skills, like supportiveness (31%), caring (20%), or maturity (16%), which are skills we tend to associate with authority figures. Even some of the traits we associate with strong leaders, such as ambitious (26%), courageous (21%), and independent (6%) were near the end of the list.

So relax about the mysterious or complicated stuff you read out there about leadership. As a tech lead (or an aspiring one), you’re probably in awesome shape already — so keep on doing what works!

Monday Motivation. An Open Letter

Dear consultants and engineers,

Last week was not a good week for me. So this morning I feel like writing you an (open) letter to talk about my expectations and my aspirations for our week together.

Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to to, let us concentrate rather on explaining to human beings what we want a computer to do. – Donald Knuth

Code is our currency. It is what we are paid to do, no matter what level you’re working on it: if you’re one of my architects, you’re thinking at high levels how big components of code work together. If you’re one of my junior consultants, you’re probably banging your head against some legacy API and worrying whether you can get your story done.

Coding is a deeply analytical activity. It requires that we sit (or stand) still for long periods of time to read, think, prototype with a REPL, wait for build servers, read stories, so on and so on. That’s what we do, and you usually do it in isolation. You’re here because you’re good at it and my expectation is that you take pride but be humble.

Now here’s my aspiration for the week (no matter what level you’re at): increase your energy level, shake off impostor syndrome, and get social about your code.

  • Ask people sitting next to you to pair up for a few minutes.
  • If someone asks you a question, sit down with them and crack open the code.
  • If you’re trying to explain status, throw some code up on the screen.
  • Call a code review for a hard problem you’re working on.
  • Show off something you’re proud of.
  • Talk through a new pattern you found in the open source world from your side project (if you have the time to have one, no problem if you don’t).
  • Can’t find a meeting room? Invite some team members to lunch. Print out the code if you have to (remember what printers are?).
  • Working remote? Get on a video call and have lunch together and screen share.

And don’t just share some gist on Slack. I know that’s more effecient, but it’s not effective and it’s not accomplishing what I want. Read on for why.

Warning: you’re probably going to have to boost your energy level to do this — I know — but it’s worth it. After writing or staring at the computer for hours, you might not feel like you’ve got the energy to get up, walk around, interrupt other people, and engage. Most of us barely have the energy to make it through the day, I know. But what’s interesting is that if you spend energy, you actually get more of it. And by investing the energy in your team or your company, they get more too. It all starts with you, and you’ll be well on your way to leadership by these small acts.

By the way, if you feel unsupported by anyone on the team or in the organization, I want to know right away.

Make it a great week folks and let me know how the social thing works out for you.

Everything you will ever do as a leader is based on one audacious assumption. It’s the assumption that you matter. Before you can lead others, you have to lead yourself and believe that you can have a positive impact on others. You have to believe that your words can inspire and your actions can move others. You have to believe that what you do counts for something. If you don’t, you won’t even try. Leadership begins with you.

-The Truth About Leadership

Short projects are hard

Short projects are much harder than long ones. I’m talking about super short development projects, like four weeks plus or minus a few. First, software engineering is almost always harder than everyone thinks, but in a small project everyone assumes that it’s going to be easy. It never is, is it?

Second, the amount of time you have to establish credibility compresses so tightly that it’s easy to completely blow it in just a few days. Trust and credibility usually take time to develop, but if the project only lasts four weeks and you have a bad demo on Tuesday of week two, you may never recover your credibility before the project ends.

Third, nobody takes the time to analyze everything. Realistically, few will invest much more than a few hours to scope out a project that’s only going to last a few weeks, so they build in a lot of assumptions to short cut the process.

Sure, big projects have a lot more on the line, more eyes, and more pressure. But in a long project, there’s time to absorb some of the inherent risk in all software engineering projects and time to build credibility or restore it from a few missteps and the stakeholders usually invest a lot more analysis into it. Short projects are white knuckled with none of these luxuries.

What to do about it

Only use senior engineers who have demonstrated tech leadership abilities. Don’t even try this with a junior engineer who’s still learning — even if it costs a lot more. You’re probably doing short project because you’re hoping to get follow on work, so don’t blow it by trying to turn a profit on this one; make it up on the backside (hopefully).

Raise the risk before you agree to do it. This is hard because clients are likely to be dismissive and you’re struggling to build credibility. They might tell you it’s just going to take a week. But if you remind them that software development is hard, they usually agree to add some buffer. This is software engineering, and one week can turn into eight. Bigly. Mature clients know it.

Ditch the traditional agile processes and two sprint timelines. Be truly agile in your delivery not your processes. Invest more into management and project oversight time than you would on a short project. One or two day sprints if you must follow the process.

Build credibility with the client by demoing as often as possible but at least a few times per week. Daily if you can. Nothing to demo? Demo code. Lots of demos gives you the ability to course correct and build credibility quickly when the inevitable issue comes up.

Offset some of the risk by increasing stakeholder involvement. Stakeholders might be tempted to be dismissive of of their need to be involved in a short-term project. Make them show up to demos or suspend your work if they claim they’re too busy.

What to do if you get off track

Communicate, but do it at a detailed, code level. Remember, even when you’re off track, you’re still trying to use every minute to build credibility and trust with the client — and you need them to support you for more time.

What do you think? How do manage short projects? Did I miss anything? Leave me a comment or hit me up on Twitter @michaelrice.

Managing software engineers is straightforward, leading consultants is not

Wikipedia defines herding cats as an “idiom denoting a futile attempt to control or organize a class of entities which are uncontrollable or chaotic.” That’s about right when applied to software engineers.

Despite cat herding, managing is (relatively) straightforward

If you ask a team of three software engineers to write some Javascript to say “hello, world” after a user clicks a browser button, you’ll get at least six solutions. The first will copy and paste some crap from the internet and promptly return to Hacker News. The second will agonize over the naming of her function and put some exotic js dependency in the project. The third proposes three different — half completed — options, one based on Elixir/Elm, with an abstracted object model for transporting messages like “hello, world” across the wire and complete with a specialized Jenkins plugins to Dockerize the whole thing and deploy it to Kubernetes.

For all the high minded conversations about agile, sometimes I honestly think it came when the folks in Snowbird finally said in exasperation, “Guys,* can’t we just agree to build one, small, useful thing… and then go from there?!?!” And agile was born.

With agile now mainstream and mature, it’s a relatively straightforward task to keep track of software engineers, to fix blocks when they come up, improve effectiveness, happiness, and etc. — at least relative to what it was like back in the 90s and early 2000s. It’s a lot of work, but it’s pretty well-known.

I’m down to two major problems these days: inexperienced engineers and inexperienced senior managers. There are still far too many software engineers who don’t embrace the agile mindset. They claim to know the ceremonies and come with years of “agile” on their resume, but they learned bad examples or are resistant to the mentality. In either case, my job isn’t about managing, it’s coaching and evangelizing, which is fun when it works.

The second problem is a harder to solve. To grossly overgeneralize, I find many senior managers are warming (or just resigned, possibly) to the idea of delivering incremental value on the West Coast where technology is so dominant. On the East Coast, the big, traditional firms still have a way to go — and that makes the manager’s job tough.

Now, let’s increase the difficulty level; let’s talk about leading traveling consultants

I’m not a software engineering manager working in one environment with a fixed number of engineers day after day. There’s a lot of great stuff written about that role and even conferences now. Instead, I manage consultants who might show up on a client site for just a few hours. There’s almost nothing written about how to be successful doing this.

In both roles, the job is to optimize the value the software engineers produce. Roughly, there are three parts: make sure the project management process it working, help the individual contributors be effective,  and setting expectations up and down.

How managing consultants is different

That’s about where similarities end. First, the pressures feel higher. Unlike an existing, in house development team, bringing in consultants hits budgets in a different way, appearing expensive, so the demand for value goes up. It doesn’t help that clients don’t always need to develop long-term relationships with you, so they sometimes feel free to squeeze.

Second, I work with many different consultants, many of whom I’ve never met and don’t deeply know their temperaments or capabilities, which is something I would care about if I were managing a high stakes internal project. Third, I run too many projects to be onsite enough to coach or manage all the little, but important, things that engineers need to do all day to be effective, let alone the deep details of their project backlogs or the code. My direct reports are only occasionally on projects I manage.

Ways to deal with it

I’ve noticed that people in my role seem to react to it in two (overgeneralized) ways. One reaction is to switch into an administrator type role. This is a natural reaction when you’ve got a lot of engagements with diverse technologies all at once. The second is to stay tightly involved in one technology and/or one industry, which is something I saw a lot at Accenture.

Instead, I’m trying to figure out how a consulting manager can produce highly effective results no matter what technology and across many, diverse projects simultaneously — in other words, how to scale.

I think it comes down to the fact that, at scale, the most you can do is a rough kind of high level, tracking-style management. To be effective, you have no choice but to scale up by  focusing on your own leadership skills. You can’t manage consultants to where the team needs to go like you can when you’re in house.

More on this to come when I find the time…

Kotlin: Let’s Kill the Dreaded Java Null Pointer Exception

I’ve been spending some time with Kotlin this weekend. While I’m still getting to know Kotlin myself, it seems like a language that’s worth your time as an enterprise developer, particularly if you’ve got a legacy enterprise Java code base that you can’t realistically migrate en masse. Helpfully, Kotlin can run side by side with that legacy code and buy you modern language features incrementally (more on this later).

nullpointerexceptionKotlin has many benefits — from cleaner, more succinct enterprise code to modern, functional capabilities (especially with funKTionale). In this post, I want to drill in on a mundane issue, an issue near and dear to many enterprise Java developers: solving the dreaded null pointer exception problem, a problem also known as the “billion dollar mistake.”

First of all, Kotlin takes an oblique approach to the null pointer problem: it simply doesn’t allow accidental null pointers. For example, you can’t do the following because you’ll get a compile error (try it yourself):

If you must have a variable that might be null, you need to demarcate it as optional with the following (clean, IMO) syntax:

Notice the question mark? As you might have guessed, it denotes a variable that could be null, which is similar to (but so much more succinct than) Optional in Java 8+ (or similar Guava features).

Given that syntax, the Kotlin compiler is able to provide you substantial null safety. In the following example, it is always going to be safe to ask for the length of the string in name because the variable name can never be null — ever.

However in the next example, if you try to compile code that checks the length of the name string in example 2 without checking for null first, you’ll get an error.

Let’s look at a somewhat more elaborate example:

In this example, we have two classes where the Address of a Person could be null. We also have some instances of people, one of which can never be null and one that can. Again you can see the compiler won’t let you directly access a nullable variable null without handling the possibility of the null (with the “?” syntax above).

The Kotlin compiler is smart about null safety in other ways too:

As you can see, in the first example, the compiler detects when you access the address field within a null check, which is a pattern familiar to Java developers (maybe painfully familiar?), and lets you proceed.

The second example is a little more interesting and succinct. It shows how you can use the Kotlin elvis operator to safely access a variable that could be null. The first part will print the postal code if it’s non-null and the second, optional, operator (?:) will respond with a different string when address is null — no if statements required!

Also interesting to note in the examples are the string templates, which we will discuss in another post.

Hello, world with Kotlin and Maven

Kotlin seems like an interesting language for Java enterprise developers who want to introduce a new simpler language with modern functional features but who can’t realistically leave their legacy Java code behind. Also, Kotlin is super easy to read, learn, and code — IMO, anyway.

I noticed a lot examples are based on Gradle. I think Gradle is great. But since most of the Java developers I work with are used to Maven and the project object model (“POM”), I thought this post might be somewhat useful for you. First, we need is a simple Maven POM:

Next, create a file named hello.kt in src/main/kotlin. Create a new source file named hello.kt (the name is important) and add this code:

You can see right away that Kotlin is different: the function is named differently, the arguments are defined differently, and there are no class references anywhere — even the function lives outside a class!

How to Run It

So that’s easy enough to get your Maven project set up for development. But what do you do with it? And how do you actually run it in the real world?

Inside the IDE

If you’re running in JetBrains’s IntelliJ, running it is as simple as clicking the Kotlin icon (among other methods):

Easy but obivously only useful if you’re code will never leave the IDE.

Assemble an Executable Kotlin Jar with Maven

To build a JAR that you can execute in a runtime environment, we’ll need to do some more work on your pom.xml file. In the build section, you need to add two additional plugins. First is the jar plugin:

This is a standard Maven plugin for adding a MANIFEST.mf file, which will tell the Java runtime which class to execute.

You might notice the mainClass element contains the cryptic looking word “HelloKt.” When you go a little further with Kotlin, you’ll learn that it’s completely interoperable with Java. When you want to call Kotlin code from Java, the Kotlin compiler names your classes with Kt suffix appended to the Kotlin source file name.

In our case we named our source file hello.kt, so Kotlin will expose our code to the Java world as HelloKt. You can override the naming with annotations, but I’ll save that for another post.

Now you can assemble an executable jar file. To run the file, however, you’ll need to put additional runtime Kotlin libraries on the classpath. So let’s build a fat jar with the runtime dependencies baked in by adding one more standard Maven plugin in our Maven build process:

Now drop into your command line, run mvn package on your project and you should be able to execute this command:

And Hello, world!

For More Information

JetBrains has a nice, succinct Maven guide for Kotlin with current version numbers. Also, this code is available on my Github account here: https://github.com/mrice/kotlin-maven-hello-world

kotlin_icon

Thanks to a comment from Eric for causing me to update the example with some guidance on how to actually run it!

Software Stranded Me in New England for Four Days

Craftsmanship in software matters to our lives more and more every day. I am reminded of that now that I am stuck in New England for four days because of a glitch with Southwest Air’s backend systems.

The only thing we seem to know about the root cause right now is that there was an issue with a “router,” but who knows what kind? Maybe a network router or maybe it was an API router. Maybe the hardware burned up, but more likely it was some kind of failure deep in the software stack of the device. Worse, for some reason the fail over systems failed too. Southwest reportedly had to “reboot everything” to get the whole system up and running again.

How ironic it was that I was reading about SOLID principles (an important aspect of craftsmanship) in functional programming in the Providence airport as all hell was breaking loose around me. Little by little my phone kept buzzing, letting me know I was getting increasingly delayed and then finally cancelled. The system failure was so bad that they can’t get me on a return flight until four days later.

Only a few years ago Southwest was able to issue paper boarding tickets and recover with old fashioned manual systems. These days, the software is so deeply intertwined that the failure was more massive (almost 1,200 flights cancelled). There was no way to recover.

Getting it right in software is more important than ever. Craftsmanship is one way to do it.