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.