Making Sense of Blockchain

If you’re like me, you are probably trying to make some sense of the hype (and hysteria?) around blockchain. While the concept of blockchain is fairly approachable, the applications of this technology (beyond the obvious financial transaction ledgers) is not.

I have spent some time and thought trying to identify some analogies from our past that might provide a framework for watching and observing the trends surrounding blockchain, and help to understand its role and its fit within our technology landscape.

My intent with this post is to put the current state of blockchain in some historical context to better understand where we are and where we might be heading.

During the 1970s, two scientists – Vint Cerf and Bob Kahn – developed a robust network protocol suite to allow distributed computers to communicate with one another. There were some significant technical challenges with their approach and several revisions of the protocol were made to improve its stability and robustness.

By 1982, the protocol was mature enough for the U.S. Department of Defense to adopt it as the standard for all military computer networking. In 1983, the protocol was put in use for a DOD-sponsored project to develop a generalized communication network among computers across the country. This network, called the ARPANET, and Vint and Bob’s networking protocol, TCP/IP, became the foundation of the modern Internet.

Even though the Internet (ARPANET) and TCP/IP were in the public domain, and broad hardware/software support for TCP/IP was in place, it wasn’t until Tim Berners-Lee developed the Hypertext Transport Protocol (HTTP) in 1989 and the explosion of the World Wide Web in the 1990s that we saw the power and capability these technologies enabled.

Today we continue to see amazing capabilities built on top of this foundational technology; smartphones, video streaming, voice-enabled smart homes, and on and on. I suspect that Vint Cerf and Bob Kahn are amazed at what has been built upon their work.

What does this little history lesson have to do with blockchain? The way I view blockchain is the way I view TCP/IP. Blockchain is not a product in and of itself. It is a technology that I believe will become the enabling foundation of products and services that we can’t even imagine. Given that it took 10+ years for the World Wide Web to emerge from the early TCP/IP-enabled ARPANET, it may be some time before we see the true breakthroughs that blockchain will enable.

Much like early TCP/IP, blockchain has significant challenges to overcome. However, I don’t think we are going to have to wait 10 years to see its benefits in our lives. The fact that our connected world allows us to share ideas and thoughts more easily today than in the early 1980s (due to technology and products enabled by TCP/IP!) means there will likely be an acceleration of innovation that significantly hastens the development of these products and services.

Will blockchain create massive paradigm shifts on the scale of the World Wide Web or even the iPhone? I don’t know. That said, I look forward to seeing what will become of this technology and will not be surprised if it impacts (and improves) the quality of life for people across the globe.

My advice is to be patient, keep your eyes open, stay informed, and prepare to be amazed.

 

 

This post was originally published on the Don’t Panic Labs blog.

/0 Comments/by

Where Are They Now?

,

We are not a lifestyle company.

This is a sentiment I made clear at a recent Don’t Panic Labs company meeting. It’s not that we have anything against companies where employees settle in for their entire careers, but that’s just not who we are (or ever aspire to be).

I’m not saying anything new here. This was pretty much implied when we formed Nebraska Global/Don’t Panic Labs back in 2010. We never intended to build a place where people spent all of their working lives. We wanted to grow the entrepreneurial spirit in developers and engineers by exposing them to what it takes to launch a software product/company, all with the expectation that some of them would pursue these types of endeavors.

As I was drafting my Nebraska Global reflection post, a few software engineers came to mind as I was thinking back to our early days: Paul Bauer, Nick Ebert, Rich Kalasky, Nate Lowry, Cody Leach, and Spencer Farley.

Most of them were with us from pretty much the beginning and were key to getting Nebraska Global/Don’t Panic Labs off the ground and helping build what became EliteForm, Beehive Industries, and Ocuvera.

As new opportunities were presented to these guys, they listened to the inner voices calling out to new and challenging roles outside our walls (figuratively since Nate is part of Travefy and Paul is part of Ocuvera, both in or adjacent to our location). Seeing them go was difficult (the talent they possess doesn’t just walk through the door every day). However, I understood that this comes with the territory and fits exactly into what we wanted to see happen with Nebraska Global/Don’t Panic Labs.

We reached out to these guys to have them share what they’re doing today and what they’ve learned along the way.

Paul Bauer, Product Manager at Ocuvera

My main goal is to build the bridge between the development team and the outside world, to make sure that everything we’re working on is the right thing and is solving problems for our customers.

As is typical for an employee of a young company, my key responsibilities are much broader than my role. I also wear the hats of sales, support, customer training, project management, marketing, and more on a regular basis. These are incredibly diverse and force me to speak several different ‘languages’ to a variety of stakeholders throughout the day.

I came to DPL as a new college graduate, and DPL provided the opportunity to experience real-world product development first hand as part of a team. Through that experience, I learned what it takes to produce real-world software. Through the attention given to software design and architecture at DPL, I learned a framework (iDesign) that I knew I could replicate anywhere to build just about any software product. That knowledge alone was a huge confidence booster which, I think, put me on a whole new career trajectory.

One of the biggest things that helped me into my current role was the variety of experiences DPL provided: I was able to sit in on sales calls, visit customer sites, learn about user interviews from UI/UX engineers, attend conferences, contribute to marketing copy, and so on. Nobody told me, “that’s outside of your responsibility,” instead they encouraged me and gave me more opportunities. My definition of software expanded beyond just code to include everything else that goes into running a software business. I discovered that those non-developer activities were really fun for me, and I missed them when I sat at my computer coding all day. All this made the move to my current position a smooth and natural one.

My advice to aspiring software developers is that working on the same team as more experienced people is a super-effective way to learn. Don’t view your co-workers as competition, view them as people you can learn from.

Nick Ebert, Director of Engineering at Spreetail

I focus on the health/well-being and growth of the Spreetail Engineering team, so I do a lot of recruiting and development of people. I also work to remove technical barriers that are preventing the growth of the company’s software.

I was introduced to a breadth of different technologies and processes during my time at DPL, which has helped me quickly understand new systems and software architectures. DPL team members are very authentic, and that trait has stuck with me in my current role.

I would advise aspiring software engineers (at any level) to write code every day. Simple, right? One of the things that makes software engineering so unique is that there is very little overhead to get to build something. You can go from vague idea to running software in a matter of hours.

Rich Kalasky, Applications Development Architect at Buildertrend

At a high level, I am leading the technical direction for Buildertrend on our web application and services. Day to day, I help break down new features, mentor developers, and generally help set the tone for our department.

Working at DPL gave me a deep introduction to the .NET stack and well-designed software in general. After joining Buildertrend, I was able to quickly ramp up and start building features on a similar tech stack. As my role has expanded, I find myself reaching back to my experiences at DPL and applying them to new problems constantly.

To engineers coming out of school, I would suggest finding a place where you are the dumbest person in the room. Become a sponge and soak up everything you can from the smart people around you. DPL was this place for me, but there are plenty of others (including Buildertrend!) that can provide a similar experience. There was so much accumulated software knowledge in the building every day it was impossible to NOT learn something.

Nate Lowry, Software Engineer at Travefy

I am a software developer for Travefy. We’re a small team, so I code anything from web frontend, backend, services, and everything in between. I led design and development of our Public API and am in charge of our plethora of mobile apps. I’ve also been involved as a technical contact in some of our enterprise sales.

At DPL I learned to do just about anything. It was a fast-paced environment where we didn’t use titles or hierarchy, we just got stuff done when it needed to be done. Working with lots of different clients also helped me understand the importance of communication, transparency, and feedback.

For developers and engineers coming out of school, I say go try something. If it doesn’t work out, try something else. Work hard. Have fun. Be happy. Make time for things outside of work.

Cody Leach, LeverageRX

I’m the CTO at LeverageRx, an online platform that helps doctors make smarter financial decisions. I’m currently the only developer on the team, so my responsibilities include everything under the product umbrella. It’s up to me to keep the site running smoothly, to make technology decisions as the business grows and evolves, and to keep a pulse on the business and foresee upcoming technology needs. Most importantly, I work closely with my business partner to make sure I’m designing and building our platform to solve the right needs of our customers.

I started at DPL as an intern my senior year of college, which eventually led to a full-time position with the company. I had the luxury of being a full-stack developer at DPL, but I was also the lead UX designer on most of the projects I was involved with. When I started as an intern, I didn’t really know much about developing “in the real world,” and I knew even less about UX and UI design. I learned a ton about working on a development team, what is (and isn’t) great software architecture, how to balance business needs with product needs, and how users interact with your product and how that impacts the business, among other things. In my current role at LeverageRx, I am constantly making product decisions that have a direct impact on the business. The development structure and discipline I learned right out of college has been a huge factor in helping me make these critical decisions.

What advice for aspiring software engineers is two-fold:

  • It’s okay to fail. I can’t tell you how many times I’ve built crappy software or designed a horrendous user experience. Without these failures, I wouldn’t have learned as much. The best part about embracing the failure mindset is that it keeps me learning. If I don’t fail, I’m not learning.
  • Pay attention to how people use your software. If your users can’t figure out how to use your software (or if they hate using it), then what’s the point of making software? Great software AND great user experience is where the real magic happens.

Spencer Farley, CTO at ScoutSheet

I am currently CTO at ScoutSheet. My responsibilities include everything related to creating the product. I teach interns, user test, program, formulate architecture, glean requirements from user feedback, collaborate with the business people to brainstorm and test high-level direction based on market analysis, QA. The list goes on.

DPL prepared me for this kind of position by giving me ownership over products and teams. In particular, the Backlog Management project taught me a lot about the end-to-end software process. Project Managers Todd Guenther and Lori McCarthy educated me on project management and were candid customers. I felt the sting of delivering a sub-par product and how much testing processes can improve a product. I got to architect the system, feel what didn’t work, and fix it. I got to experience managing a team and balancing teaching versus getting stuff done. Doug also met with me regularly and we conversed about architecture principles. We also read books together, which was very formative to my dev skills.

My advice to graduating software engineers would be to realize there is still much to learn. Working in a commercial environment is a different beast and it will take time to learn the many concerns outside of syntax and performance (e.g., maintainability, reliability/test-ability, changing requirements,…). The best place to get started is to pick up classic literature of the field. Mythical Man-Month by Fred Brooks is a good place to start.

 

 

This post was originally published on the Don’t Panic Labs blog.

/0 Comments/by

The Importance of Context in Engineering

,

People who know me understand how strongly I feel about experiential learning. I have often talked about how valuable I believe my own personal experiences are and how I feel they impact the way I see and approach problems. I even wrote a blog post talking about how challenging it can be to work with bright but inexperienced people.

Recently, a couple of things happened that brought this whole idea of context and experiential learning back to my mind.

First, I was talking to the parent of one of our interns who just finished his first year at UNL as a Computer Engineering undergraduate. As with many students entering engineering study, the first year can be quite challenging. While he made it through, I think there were times during the year when he got a little discouraged. After the first few weeks of his internship, he expressed to his father that working on projects here has already given him a great perspective on what a software engineer really does and why the education is important. Essentially, he is learning the applied side of his academic education.

Second, I was reading Joshua Foer’s “Moonwalking with Einstein: The Art and Science of Remembering Everything” and came across a section that discussed the importance of having knowledge and experience in order to gain knowledge and experience…

“This paradox – it takes knowledge to gain knowledge – is captured in a study in which researchers wrote up a detailed description of a half inning of baseball and gave it to a group of baseball fanatics…and a group of less avid fans to read. Afterward, they tested how well their subjects could recall the half inning. The baseball fanatics structured their recollections around important game-related events, like runners advancing and scoring. They were able to reconstruct the half inning in sharp detail. One almost got the impression they were reading off an internal scorecard.

“The less avid fans remembered fewer important facts about the game and were more likely to recount superficial details like the weather. Because they lacked a detailed internal representation of the game, they couldn’t process the information they were taking in. They didn’t know what was important and what was trivial. They couldn’t remember what mattered. Without a conceptual framework in which to embed what they were learning, they were effectively amnesiacs.” (Foer 2011, p.208)

Both of these events reminded me of how important it is to have context and personal experience to be able to minimize errors in judgment. This is why I have stressed to underclassmen (and even high school seniors) that the time to start getting internships and real experience is not when they are juniors and seniors but when they are high school graduates and college freshmen. Any and all real-world experience will help provide the framework for “embedding what they are learning” in the academic environment and, what’s more, the absence of these experiences will diminish the value of their educational efforts.

Our educational systems can help with this as well. I can think of two examples in our figurative backyard that are moving in the right direction.

The first is the Design Studio program at the Jeffrey S. Raikes School of Computer Science and Management at the University of Nebraska-Lincoln (UNL).

The second is the upcoming Software Engineering undergraduate degree at (UNL) which will be launching in the fall of 2016 and will likely focus on the knowledge, activities, and behaviors that are important for anyone pursuing a career in software development. This program will include two years of capstone experience similar to the Design Studio in the Raikes School.

Now, if we can only get the Nebraska State Board of Education to recognize how critical it is for all kids to be exposed to computer programming as part of their required curriculum. But that is a topic for another day…

Ultimately, I want to see more and more emphasis placed upon applied learning and more hands-on design and development of real-world systems in the classroom setting. Imagine what would happen if we re-engineered our educational systems that are developing engineers to focus more on experiential learning (which is how we used to train engineers before the computer age).

If you are interested in reading more about the nature of engineering and design, I recommend this article by Eugene Ferguson from 1977 or, better yet, the book he wrote as a follow-up to the article. Chapters 6 and 7 focus on the development of engineering knowledge and the making of an engineer.

 

 

This post was originally published on the Don’t Panic Labs blog.

/0 Comments/by