Working with IPFS locally, did you hit the “no ‘Access-Control-Allow-Origin'” error?

So did I. 

If you’re doing decentralized application development, eventually you’re probably going to want to play around with the Inter Planetary File System (“IPFS”) because you simply can’t (and don’t want to) store too much data on the blockchain. 

My problem came up when I was doing some local development with a local node and a local React application.  I wanted to connect to the local instance of IPFS daemon using something like the following code from my React app (edited a little to simplify):

Of course, when I tried to run it, I hit the dreaded cross site security issue that CORS was developed to help with.  It’s pretty generic and not at all unique to IPFS.

Surprisingly, there isn’t too much written on the web on how to resolve this.  Simply disabling the browser’s security didn’t work because the IPFS local endpoint was configured to reject the cross-site request.

Long story short, all you have to do is change the local IPFS configuration. Start by editing your config file by using something like the following:

Now change the “API” section of the config file to look something like the following:

Restart your IPFS daemon and you should be good to go. 

Good luck out there and let me know how it goes for you!

The Solidity “out of gas” error… you’re probably not really out of gas

This is my first week at OpenLaw, a Consensys spoke, where I get to not only do a little legal work as a legal engineer but also get to do some blockchain engineering, especially Solidity development.  I’m currently working on version 0.4.24.

But as you probably know if you dabble in Solidity, it’s still early days and a challenging platform compared to more mature languages! 

For example, for a few hours this afternoon I was absolutely flummoxed with the following error when running my Truffle tests:

So I diligently checked my Ganache settings and tried to change the gas settings on my Truffle transactions.  No dice. 

It turns out that this error is probably a red herring.  The more likely cause is that there’s an error in your deployment somewhere.  

It’s probably not a problem with your code (lightly speaking), or it Solidity wouldn’t compile.  However, it could be something that’s sorta, kinda related to your code.

In my case, everything was working until I tried to pull some contract names up into interfaces and had naming collisions even though I thought I had organized my code properly to avoid them.  Others have reported similar issues such as not implementing constructors from parent classes properly.

So, long story short, if you see the check-your-gas-amount “error” it’s probably not a gas issue — you probably have an issue lurking somewhere in your codebase.

Hope this saves you an hour or two….. good luck out there 🙂

What to do with the Swift REPL “NameError: name ‘run_one_line’ is not defined” error

I was playing around with Swift this weekend. Every time I started the REPL (whether version 3x or 4x of Swift) I got a whole bunch of errors that look like this:

The REPL would work fine, but you know…. it was really, really, really, really annoying having to look at that error. All 100+ times it got repeated.

Turns out that the Swift REPL depends on a Python library called six. You may be able to quickly install it using this command:

Problem solved……?

Good luck out there!

 

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…