Every project we tackle as developers tends to be an opportunity to learn new languages, design patterns, abstraction layers, and service structures, all while growing our careers. As software engineers, we are expected to be flexible enough to solve problems and specifications in various contexts, from more classic technologies like PHP to newer, more emergent ones like blockchain. 

Blockchain is a buzzword that has gained in popularity ever since the first block of Bitcoin was mined in 2009. The term has been associated with several adjectives, good and bad, but the truth is this technology results from thinking out of the box and coming up with a solution to numerous problems. 

For the past year and a half, I’ve had the opportunity to work on a Blockchain-centric project, researching and integrating different platforms to interact with them. Read along as I break down some of the main areas in which I’ve improved my skills and learned some lessons.

Performance

Blockchain is, simply put, a very inefficient database. This is because performance is sacrificed in favor of having a permanent ledger whose entries cannot be changed or tainted by a malicious actor. As the name suggests, when we talk about blockchain (the database), we’re talking about a chain made out of blocks (database rows). In each block, we have data that, once registered, is used to connect the next block in the chain to its predecessor. If you change a past block, the rest of the chain won’t make sense. Each new block confirms that all past blocks are valid, and so is all of its data.

This comes at a high cost to query and read the data inside or submit new data to the chain. As engineers, we already have to work with performance in mind, but in interacting with the chain, we’re working with a system with some limitations that play against us in this area. Big O notation, clean code practices, taking advantage of asynchronous calls when possible, and many more tools are in our belt to compensate for the relatively slow performance we already have in a blockchain system.

Security

Blockchain is known for its secure foundations and the cryptographic tools used to make a decentralized system a trusted system. To build and deploy secure code that interacts with blockchain platforms, we must follow safe practices that enable our system to be as secure as the platform we’re interacting with. Identities in blockchains are non-existent. The way a system that doesn’t need to trust anyone works is with keypairs and cryptographic signatures. Working with these tools and learning how to do so securely is a constant learning process.

Working with third-party packages and modules has also taught us how to work with InfoSec engineers to routinely assess the code we bring from the outside and follow specific security processes. We always work with software that we built from source code that was previously looked into. All this software is containerized, and activity monitors are in place to keep a constant eye on everything happening inside the network.

Improvisation

The number of blockchain platforms out there has been steadily increasing over the years. All these systems compete with each other, trying to be the most radical, secure, interesting, and, above all, most promising to have any value in the future. To do that, blockchain developers and creators have to develop clever ways to make their platforms have all the functionality they need without compromising on security or accessibility.

Sometimes blockchains are not even blockchains, but what they call a “mesh,” where the ledger doesn’t have the mechanics of blocks but data structure nodes validated by two or more other nodes. Other times, the platform is focused on privacy, and you don’t have access to any data that doesn’t have your public keys as an origin or destination. UTXO transactions, meshes, memo tags in transactions, and many others are cases for which we have to improvise and come up with abstraction layers, so the differences between platforms are of no concern to the system we’re building.

Code Quality

Code reviews in our team of blockchain engineers are the way we ensure that the whole team’s expertise brings value to every single line of code we deploy. We have different stages of review in which teammates from both the Wizeline team and the client’s side can look at what we built. Feedback, criticism, and discussion are the day-to-day activities in our code review process. I have to be honest here and admit that this is not something exclusive to our blockchain project, but a common practice in projects across the board at Wizeline.

I can say that in the year and a half that I’ve been working with Wizeliners, I’ve improved my tech skills more than I did in the previous four years working as a freelancer.

Being a Blockchain Software Engineer

At the end of the day, we’re software engineers working on a specific technology like most SWEs in the world. It just so happens that the technology we work with encourages us to think outside the box and create clever solutions to seemingly complex problems. Since sometimes we have to work directly with assets and tokens, it is also a great playground to learn the best coding and security practices.

Being able to do this in a company like Wizeline, where I’m also able to improve my technical and leadership skills as needed in the career path I’ve chosen for myself, has been one of the most rewarding experiences in my professional life.

I know that I won’t be working with blockchain technology forever; someday, I will move to other technologies. Still, I’m sure that everything I’ve learned working with blockchain will stick with me, making me aware of the implications that tech decisions have on the final product and how the end-user will interact with it.