Our Future in Software Development

My profession has changed significantly over the years. I entered this profession back when I was a teen – doing contract jobs for companies near where I lived. Mind you, during that time, the internet did not exist and contracting meant going on-site to the company that needed my services and actually working on their equipment. There was no PC being used in business back then – the Apple II and the TRS-80 were state of the art for enthusiasts, but rarely used in business. Even if a company did have an Apple II, it was limited to single station processing as there was no such thing as a network, wired or wireless. I personally never witnessed anyone using a TRS-80 for business. I’m not saying it didn’t happen, I just never witnessed it.

Yep, we were carving symbols out on rocks!

I still remember the day a friend of mine got an Apple II computer. We were stunned that he had this in his house and was able to create programs in BASIC and store them to a floppy disk. Not only that, but he create a program that he could run to actually open and close the shades in his bedroom. How cool! Another buddy of mine had a TRS-80 and the storage system on his computer was a cassette drive – for those that don’t remember, this was a painfully slow way to load data/programs into memory. Additionally, the TRS-80 regularly lost information on the cassette tapes. It was not uncommon that you had to store something on 3 or more different cassettes to actually ensure that you had a copy that worked.

Today, I wear more computer power on my wrist then what was available on the mini-computers that I was programming back in the day. Seriously, my Apple Watch 3 has 768MB of RAM and 16GB of storage. The S2 processor on the Apple Watch 3 runs at 780 Mhz. As a reference the IBM 5110, which was the first computer that I professionally programmed on, had 32K RAM (could be expanded to 64K), with two 1.2Mb floppy drives and a processor that ran at 1.9Mhz. The IBM 5110 had a retail price of $10-20k depending on options, it had a 5 inch black and white screen (16 lines of 64 characters) and weighed over 40 pounds. And yet, somehow we made things work!

My how times have changed!

One of the first professional programs that I wrote managed a customer list for a business using the IBM 5110. The customer information was spread out over multiple 8” floppy disks (side note: I still have copies of the original programs and data on the 8” floppies – not sure I could even find the equipment to read them at this point). During processing of the list, the computer would prompt you to change the floppy disks so that it could continue processing the data. It was clumsy to say the least and meant that someone had to babysit the programs when they were running, changing disks back and forth as needed. And to complicate matters further, there was no such thing as a database – your data was written to fixed length ASCII files and you had to manually read/write and manipulate the data off the floppy disks. All those fancy things that SQL does for you in retrieving, manipulating, sorting, summarizing and managing data, had to be done by hand. I remember spending huge chunks of time writing generic BASIC PROCs to handle common functions that can now be done with a single line of SQL.

Creating the programs was interesting to say the least – there was no internet to look things up or to turn to when you needed help. You pulled out the programming manuals from IBM and you were on your own to plow thru the manuals and piece information together. The IBM 5110 could be programmed either in APL or BASIC – you literally had to flip a switch on the front of the computer to tell it whether the programs you were running were written in APL or BASIC. I wrote the programs in BASIC and they were not structured – lots of GOTO and load PROC statements. I think back on how I created those programs now and shivers run up and down my spine. But, that was just the way it was done. That was cutting edge back then – remember, the IBM 5110 was the precursor to the IBM PC.

If you want a blast from the past, check out the IBM Reference Manual for creating BASIC programs on the IBM 5110: http://www.bitsavers.org/pdf/ibm/5110/SA21-9308-0_IBM_5110_BASIC_Reference_Manual_Jan78.pdf

Today, I don’t program during the day. My role is different, and that’s ok. I’m leading 120+ team members, ranging from our Enterprise Architect and Tech Leads, to Software Engineers, to Quality Assurance Analysts and Test Automation Teams. So my coding is limited to my playing around at night to keep my skillset relevant and to ensure that I can still engage in technical conversations with my teams. Occasionally, I will do some volunteer work – coding where I can make a difference for a non-profit or helping out when a business owned within my family needs some coding done.

Lately, I’ve been creating an application using Ruby on Rails with the backend database running on MySQL. What a leap from the old days! Ruby, used correctly, is a dynamic, interpreted, object oriented programming language. The addition of Rails provides a full Model-View-Controller framework that can be used to quickly build sophisticated web applications. It provides the underlying framework for accessing various databases, providing the web services layer and generating the web pages for the application. What used to take me hours or days to accomplish writing out programs on the IBM 5110 I can now do in a matter of minutes. I spend a few minutes describing an underlying table, then I tell Rails to generate the scaffolding around that table to create a base controller and view that I can then tweak that controls all of the standard Create-Read-Update-Delete (CRUD) activity. The screens generated are not pretty, but they get the job done and I can then go back in and tweak them to give them the look and feel needed by the app. I can also tweak the controller to add additional business logic where it is required to meet the needs of the business.

I’ve also been playing around with a personal application I’m writing for the iPhone and Apple Watch. I’m using Swift for that particular effort. I’m conflicted here, I love Swift, but I absolutely detest the Apple tool to create the UI/UX. The tool included in Apples development environment is not intuitive and is over complicated. I consistently get that feedback from other developers that I talk to. They love Swift, but can’t stand the way that you have to create the UI/UX for an app. In fact, I have to say that my distaste for the UI/UX development interface has caused me to walk away from the app several times, I do eventually come back to it because I really want to make this app work, but I’m looking forward to third party tools that may allow me to replace the Apple UI/UX builder. (Yesterday, Google announced that Vesion 1.0 of Flutter is now available, providing a write once deploy to both Android/iOS tool – this may be my option, although the Watch interface will still most likely have to be done in Swift.)

Think about all of this – the first programs I wrote back in the day were massive, thousands of lines of code written in a messy BASIC with undecipherable GOTO or LOAD proc commands sprinkled liberally thru the code. Additionally, variable names were limited in size and were generally cryptic – where today, you can have variable names that are very descriptive and don’t leave the next person touching the code guessing as to what a variable is being used for in the program.

Time has allowed us to mature how we approach software development. We now have languages, frameworks, tools and integrated development environments that allow us to create code that is easier to read, is more elegant in the way that it handles data and processing and also is easier for the next person to pick up, understand and modify. We have developed tools to share code that is being developed and that allows groups of distributed developers to easily understand what has changed since the last time they pulled a copy of the code – I remember sharing code by exchanging floppy disks, yikes! We have backend data storage SQL/NoSQL that allow developers to store millions of records and quickly access, manipulate and change the data. We have developed new languages that allow us to do things with a few lines of code that used to take pages of code to accomplish. The code is now written using Object Oriented models that allow us to more accurately describe the things that an application is manipulating and gives developers a better way to create and manipulate those things. We have moved to development paradigms that make us more productive – test driven development, WAGILE (Agile-Waterfall Hybrid), Agile. We have introduced tools that allow developers in disparate locations to interact and solve problems in real time – SLACK anyone?

As a profession we need to continue to challenge ourselves in how we create software. Ultimately, it is about solving real problems for people. I don’t necessarily care how sexy a new tool/language/framework is, if it doesn’t allow me to streamline how I design, code, test and deliver the solution to the customer, I have a tough time justifying using it either personally or within the teams I am lucky enough to lead.

The current state of software development has advanced significantly from the late 1970’s and early 1980’s. That said, we can’t afford to stand still, we must understand the new waves that are heading our way. How will machine learning and artificial intelligence allow us to change the way we design, develop, test and deliver software. Will AI augment or replace roles within our teams? What pressures will the cloud continue to put on us? Today you can spin up a company without having to purchase the underlying hardware to deliver your services – you can use AWS and do a pay as you go based on the actual usage of your application. Where does it make sense to put infrastructure in the cloud? Has your organization begun using containers to deliver applications and services? How is your organization dealing with the pressure to deliver features faster – sprints anyone?

Last year, over Christmas, my son wanted to explore Artificial Intelligence. So my wife and I purchased several books on the topic. After opening these on Christmas, he holed up in his room one day and came down proclaiming at the end of the evening that he had built his first AI engine to recognize numbers in images. Uhm, what? Over the summer, before entering his first year of college, he took on-line courses to further his knowledge of machine learning. He as able to do all of this by reading some books, going on-line to do research and get questions answered and then taking some on-line courses to push himself. He is much further along the curve than I was, and has access to tools that I could only dream of. His generation will be the ones leading the wave of new paradigms into the companies we all work for today. What change will they bring with them and are we preparing ourselves?

I’m excited to see where the future takes us as a profession and how it will change what we do as developers. One of my challenges will continue to be to identify how we integrate these new ‘things’ into the legacy applications we support (and, yes, that means all that fancy code you are writing right now will be legacy code that has to be retrofit tomorrow)! 

Welcome to the future …

If you'd like more information on my background: LinkedIn Profile

Follow The Data ... Software Design, Development and Testing

‘Follow the data!’ I have preached this for years. If you truly want to be a great developer, you learn the data flows!

As a software engineer, we want to be recognized as exceptional in delivering code that functionally delivers against the user needs and doesn’t introduce performance issues or defects into the production environment. We want our code to elegantly solve the problem that has been described and delights the user. If the code that we develop is a smaller slice of an overall application or platform, we want to ensure that our integration points are rock solid, that we are doing nothing to impact the ability of the larger application or platform to successfully process and perform the function as it was designed.

It is critical that as a software development professional, we teach ourselves how data flows thru the system. How does the data flow into the application function that we are developing, how does the data get manipulated by the function we are creating and what happens to the data when it leaves our function. This means breaking the data down into its discreet elements and understanding how they are manipulated ahead of us, what we are going to do with them as we execute the new or changed functionality and what happens after it leaves us.

Let’s take a small scenarios (and I’m oversimplifying the scenario to make the point) … a Cardholder walks up to an ATM and inserts their card into the machine to request a $100 withdrawl. Behind the scenes the machine captures information off of the card to send to the financial institutions Processor. The Processor receives the information off the card and checks the balance in the bank account and spits out the $100 to the Cardholder.  Mission accomplished – right? Nope!

The ATM in the above scenario is not owned by the financial institution where the Cardholder has their money deposited. So, somehow we have to settle the money between the two financial institutions. The withdrawl is one distinct component of the overall transaction. We need to follow the data from the original transaction to the end of the day when the money actually moves between the financial institution that dispensed the $100 from the ATM they owned and the financial institution that holds the Cardholders funds. Whew, done! Not exactly.

At the end of the month, the Processor must bill for the services provided to the financial institution that holds the Cardholders funds. There are specific transaction fees that get charged based on volume.
Now, let’s think about the software engineer that works for the Processor. Not only do they have to see the data in real-time and make authorization decisions, but they need to move the money at the end of the day and ensure that the financial institution is billed properly at the end of the month.

To follow the data, the software engineer needs to understand what data is read by the card reader at the ATM and is transmitted into the data center for authorization. They must understand how to match the card data up to the financial institution cardholders account to check balances, they must understand the authorization cycle and how the individual data elements in the card data are used to detect fraud and either accept or decline the transaction, they must understand how that data moves thru the system and is stored to ensure that the money moves between financial institutions at the end of the day, and they must understand how the data is used at the end of the month to properly bill the financial institution based on the type of transaction and other factors.

The software engineer cannot be sure that the functionality that they changed is working properly until they’ve tested the data all the way thru the transactions lifecycle to ensure that it settled at the end of the day and that the financial institution was billed properly at the end of the month. Testing should be designed with the full data flow in mind, not just the partial discreet transaction where the money was dispersed to the Cardholder. Again, I’ve oversimplified, but this scenario does describe the breadth of understanding that a developer must have before they can claim success.

Now add in some side scenarios – let’s say the data is used in web and mobile applications where the Cardholder can view transaction history data and initiate fraud claims. Those data usage scenarios introduce additional data flows that the software engineer must understand and validate before they can claim success.

Understanding how the data flows, where it is stored, how it gets manipulated prior to, during and after the function you are working on, is critical to understanding whether you actually can design, develop, test and deliver the functionality correctly. Knowing how to code is the simple part, understanding how the data moves and is manipulated is the hard part.

If you'd like more information on my background: LinkedIn Profile

Code Reviews - A Must For Any Team!

As professional coders, we should be concerned about the cost to remediate ‘bad requirements’ or ‘defects introduced into the code’ thru the development process. Over the years studies have shown that there is a significant increase in cost to remediate these code issues the deeper into the development lifecycle that you go. One of the most recent published studies completed by NASA broke it down as follows:

Phase	Cost to Remediate
Requirements	1x
Design	5x - 7x
Build	10x - 26x
Testing	50x - 177x
Production	100x - 1000x

In other words, if a bad requirement is not caught before design, by the time it makes it all the way into the production environment, there is a cost of 100x to 1000x the original cost to remediate the requirement. Yikes! Now, if a developer makes an error in building the feature/function described in the requirements or introduces a defect into the code unrelated to the feature/function being built, the cost to remediate that when found in production would be 10x to 100x if it was caught and remediated during the build process.

From a pride perspective, no coder wants to be seen as the one that introduced the bad code or broke current functionality. Beyond the pride factor, though, there are real hard costs being spent by organizations to remediate these issues, as well as the reputational impact with customers.

There are things that developers can do to lower the risk of introducing defects into the code base and to limit the exposure of the additional costs needed to remediate these bugs. Code Reviews are a proven paradigm that developers can use to catch these issues early and to remediate them during the build process.

Code Reviews: The intentional and systemic check of code by other developers to identify and remediate mistakes or security threats. The practice has repeatedly shown that it can accelerate and streamline the software development process and reduce the number of defects that reach production. In its simplest terms, a code review simply means that the person developing the code shares that code with other developers who review the code to:

• -        Ensure that team coding standards are followed
• -        Look for errors that can be remediated.
• -        Look for ways to ensure the integrity and security stance of the application
• -        Look for ways to simplify algorithms
• -        Look for ways to remove code that is not needed

As much as we like to think we aren’t the ones that introduce defects into the code base, we are humans and therefore the code will contain errors – those errors may be small, or they could be significant show stoppers. As professionals, we should acknowledge that fact and look for ways to mitigate these issues early. And that, my friends, is why Code Reviews became a thing!

When Code Reviews are done properly, they will address all of the above items, they will reduce time needed in later stages of the lifecycle, they will deliver hardened code into the production environment, they will reduce ongoing maintenance costs, they will foster communications within the development team, they will provide a means for more experienced engineers to mentor those engineers not as familiar with the code and they will ultimately increase the confidence and trust of the customers using the application. With all the positive impacts that code reviews can have for the developer, the team, the organization and our customers, why wouldn’t we use this well-defined paradigm to improve the quality of what we deliver downstream and ultimately to our customers.

Let’s quick review how this process looks:

1. Code Submitter (the software engineer changing the code) checks the code into the repository and makes the Code Reviewer(s) aware of the code requesting a review take place.
2. Code Reviewer opens up the code and begins to check the code:
3. Does the code do what it is actually supposed to do based on the requirements/user stories?
4. Looking for obvious defects in the code that might produce errant results.
5. Does the code adhere to the established coding guidelines that the team uses (there are tools that can automate this)
1. Code Formatting
2. Variable Naming Conventions
6. Is there Automated Test Coverage for the code being reviewed?
1. Have the tests been written in a way that is easily understood and provides clear results?
2. Have the tests been written to provide red route/green route testing – is the sample of tests broad enough to fully test the functionality?
7. Does the code adhere to the security/regulatory guidelines used by the team (OWASP for web)?
8. Does the code fit into the overall architecture of the application?
9. Does the code introduce potential performance issues that need to be addressed.
10. Is the code in the right place, are the services and methods grouped into the right places to easily be found by other developers?
11. Did the code introduce ‘duplicate functionality’ that should be removed?
12. Has the code been written in a way that is easily understood?
13. When the new code fails, do the exception messages provide clear direction on what failed and why?
14. Reviewing complex algorithms to see if they can be simplified.
15. Identifying chunks of code that are not needed anymore that should be removed.
16. Code Reviewer identifies recommended changes to the code that was submitted and documents the changes for the Code Submitter.
17. Code Reviewer discusses the recommended changes to the code with the Code Submitter in a respectful manner.
18. Code Submitter makes agreed upon changes to the Code.
19. Code Submitter circles back to Step 1.

That’s a lot of stuff! But the benefits are huge if done correctly. The beauty, I’ve seen interns and new engineers perform successful code reviews and give feedback to seasoned engineers, just as I’ve seen our most experienced engineers give guidance to our newest team members. This process in itself fosters communication within the team and opens up doors that allows the team as a whole to raise the bar and create high quality code. This becomes the expectation within the team, nobody wants to be seen as the coder that introduced a bug, they all want to be seen as experts in their chosen profession. Additionally, it gets developers talking to each other and opens up opportunities not seen in the code review process where they will begin to discuss challenges in real-time as the code is being created and not wait for the code review process to catch the issue.

I’m not saying that this will catch everything, again, we’re all human. But by using code reviews properly, we enhance our ability to catch issues early and remediate them before they impact our user community and potentially damage our reputation.

If you'd like more information on my background: LinkedIn Profile

Students - Getting Noticed By Hiring Managers!

One of the great parts of my role here at SHAZAM is the time that I’m able to take to go out and visit with many of the local middle school, high school and collegiate students interested in careers in technology. My being able to talk about the ins and outs of this industry, how it has kept me engaged over my career and to get feedback from these students lifts me up. I enjoy talking to them about the opportunities that they will have and the changes that they will be able to make along the way. 

Invariably, during these discussions, someone will ask, “but, how do I get noticed?”

Great question, how do you get noticed among the many students graduating and entering the work force. Let me walk thru what I tell students, and by the way, I’ve given this same advice to my youngest son, as he is pursuing a career in technology. This will be focused on software development and test automation.

First Focus on Your Grades: The grades you earn are important for that first professional job as you enter the working world. It is an indicator that you paid attention and took the time to understand the material presented in the classroom and that you were able to translate that into working knowledge on individual and group assignments. While a low grade will not be a disqualifier in the process, it is a barrier that you’ll need to explain. Show me where you went above and beyond on classroom assignments. Did you ever take on an extra project and share it with the class or the instructor?

Programming Experience: Doing your homework is the bare minimum. You’re going to need to explain group projects, your role in those projects, how you overcame conflict in the group and how you got people to work together. If you want a step up on other candidates that your competing with, you should look to do projects outside the classroom. Let me give you some examples:

• Expand your knowledge. Find a technology that you want to play with and start to learn it. You may not become an expert on it, but it is going to teach you knew concepts and new techniques. Are you interested in big data – show me something that backs up that statement? What about machine learning – instead of just saying you want to learn it, have you taught yourself Python and PyTorch. Even if you haven’t successfully gotten your first engine up and running, what have you learned, what can you show me, what challenges have you encountered?
• Recreate a game you like. Bring that with you to the interview and talk about the choices you had to make, what you learned from the experience and how it made you better as a developer. My son, one day announced that he was going to recreate the game ‘2048’ on his own and to one up the normal game, he was going to create an AI behind the game that would play it for him. Mind you, this was during his first semester at college, he was taking general education classes and wanted something technical to play with.
• Build a mobile app. We are all carrying around smart phones. The cost of entry for development is $0 – you can download the software development kits off the internet. A couple of years ago, we were looking to hire some new team members. I remember the hiring manager walking into my office after one of the interviews talking about how they had just completed an interview with a candidate. He walked into the interview pulled out his smart phone and started talking about an app that he had just created. So, this candidate showed he was passionate about coding, that he geeked out along with the best of them and that he could learn new technology. Winner!
• Stretch Goal – Contribute to an Open Source Project. Find an open source project that you care about, study the code and start submitting changes to correct features that aren’t working correctly. Your changes might not get accepted at first, but you will learn a lot along the way and maybe one day you will have a change submitted that gets accepted.
• Stretch Goal - Contract Program. Are you good enough that you can actually go out and take on small contracts? Maybe build a web site or a mobile app and get paid for it? This is not for everyone – you better be able to back up your claim as a developer and be able to deliver within the constraints given by the company that your taking on the effort for. There are plenty of web sites out there that allow you to bid on contract jobs.
• Stretch Goal - Volunteer Programming. Find a non-profit that needs help. These small non-profits in your community typically need help to track donors, track the details of programs they are running. Can you help them out

Use Git: As a student, you have the ability to use Git Education for free and get a bundle of software/tools that will help you as a developer. If you don’t know, Git is a versioning system that allows you to manage changes to your code and allows you to recover code when you break something. Load your assignments into Git, load the projects you created for yourself into Git. Do not share code you created under contract – that is owned by the company that paid you. Use this code repository as a portfolio that you can make available to hiring managers to show them your capabilities. Be prepared to talk about these projects in the interview. Which ones were assigned projects, which ones did you take on just to learn and explore? What choices did you face along the way? How did you resolve issues? How did you test?

Understand Testing: Whether you work in an Agile or Waterfall environment, you need to understand the components of software development and the responsibilities on the person creating the code. I’m over simplifying here, but you should be able to talk thru how you design, how you plan for testing, how you code and how you test. If you don’t understand why you should figure out how you’ll test code before you actually write the code, repeat this step as often as needed. Truly gifted developers understand the need to plan their test strategy and write their tests before they code.

Join your schools Computer Club: Take on an active role in the club. Become an officer, help run events. Has the club sponsored a hacking event? Can the club sponsor a hacking event? Can the club take part in competitions at other schools? Be able to talk about your experiences in the club, what you did with the club how you helped the club meet its mission.

Establish Relationships with your Professors/Instructors: Everyone is going to need to have a set of references when they apply. As an applicant for a job, your ability to identify instructors that you’ve had along the way who will speak positively about your participation in class and with the assigned work is a net positive for you. Remember, people like myself have relationships with many of the local instructors and we’ll ask them about your participation in class, how you worked in collaboration with other students on team projects. Many times, I’ll have instructors send me a note or stop me after I’ve met with their students and they’ll tell me students that I should get in touch with, who are the ones going above and beyond on their assignments, who works well in class and is always paying attention and helping others out.

Research Companies: As a Freshman, start figuring out what kinds of companies you want to work for after you get out of college. Do you want to work for large multi-national companies? Do you want to work for a smaller company? Do you want to live in the country? Do you want to live in a large metro area? Do you want the opportunity to telecommute? Start creating a list of companies that you’re interested in and make sure you look for opportunities to connect with those companies. Follow them on LinkedIn. Regularly visit their web site to see what the company is doing. Follow them in news articles to understand what they are doing. If they have a recruiting department – connect with their recruiters or with people in HR via LinkedIn. Find out thru your research what skills and experiences that they want students to have. As an example, one of the companies that my son eventually wants to work for leans towards hiring students with collegiate research experience.

Attend All Job Fairs: Even as a Freshman in college, you should be going to job fairs to introduce yourself to potential employers. Let them know upfront that you’re a Freshman and understand that you’re probably not eligible for internships, but that you’d like to learn about their company, what they are looking for and ask them how to stand out as an applicant. Connect with corporate recruiters from these job fairs via LinkedIn. Send them a note after the job fair telling them what you heard about their company and what they are looking for and then let the recruiter know that you’ll keep them updated on your progress. Then actually stay in touch as you move thru your educational career.

Use LinkedIn: Do not wait – as a Freshman, create a LinkedIn account. Begin following companies you are interested in. Begin following people at the companies you are interested in. Specifically, follow the companies you are interested in, find managers that might potentially hire you someday, find the recruiters in the company and connect with people in HR. Build these connections so that you can see what they are posting. When you see something posted that you can contribute to in a meaningful way, jump into the conversation. Don’t reply to a post just to reply, be thoughtful and add to the discussion.

I’m not saying every student should hit every one of the above items, but if you are just going to class, doing the bare minimum to get buy on homework, that is not how you’ll get noticed by employers and find internship opportunities, let alone job opportunities when you graduate. If this is going to be your career, take it seriously and invest the time needed to not only tackle your education, but to prepare yourself for when you want to get hired!

If you'd like more information on my background: LinkedIn Profile

Communication - Key To Your Success!

I’m a big B-52s fan. Lately I’ve been thinking about communication and thought about lines from one of their songs:

The B-52s: Communicate (Lyrics)

Boy you better communicate

Before it's too late

You better start talking

You better talk

Let loose

Before it causes problems

I look back at the days where I was pounding out code on a daily basis to where I sit today, leading a very talented team of architects, tech leads, development engineers, quality assurance analysts, test automation engineers and certification experts. Along the way, I’ve seen all kinds of challenges.

Here’s a good one from my early days …

I had recently taken a role within the company that I was working for to manage the technology within a specific department, this included not only overseeing the custom code used to manage the operations of the department, but also included purchasing millions of dollars of hardware on an annual basis to handle the growth of the department. Today, everyone takes conference calling for granted, but back then, this was relatively new technology and the company I worked for was providing teleconferencing capabilities for governmental agencies and many large corporations. I was buying conferencing bridges as fast as I could and continuing to customize our conference reservation and management systems. It actually was a pretty fun gig.

So about a year into the job, I get a new boss – a VP that flew into town every couple of weeks. The company I worked for felt that every 6-12 months they needed to shuffle the VPs around to give them exposure across different operational areas within the organization. I had already gone thru 2 different bosses at this point, so getting a 3rd one really didn’t faze me. Up until he arrived.

He walked into my office and said the following: ‘I don’t know what it is you do, I don’t want to know. If you need something, tell me who I need to talk to and what I need to say.’ With that, he walked out of my office back to his office, walked into his office and closed the door. I didn’t see him for the rest of the week and then he flew out of town, not to be seen for another couple of weeks.

Yikes! For about 7 months, I worked for someone that I rarely saw and with whom I rarely ever had a conversation. When he did fly in, he walked thru to his office and closed the door behind him. I was spending money that wasn’t budgeted, but he never even questioned me – granted, we were growing way faster than projected and even with the money I was spending, we were still way ahead on revenue. Still, you would have thought at some point, someone, especially my boss would have questioned the money that was being spent. Conference bridges weren’t cheap and the money needed to be spent to keep up with the call volume growth, but not a single question.

I left that job for a couple of reasons – first, he eventually came to me and told me that he wanted to move me out to the East Coast. I had no warning of this conversation. He just dropped it on me and expected me to jump thru hoops to make it happen. Uhm, no. He had never spent any time with me to understand what my goals where, what was happening in my personal life and where I wanted to go and what I wanted to do. He had never taken time to talk with me about what his goals were for me, where he saw me going and how I fit into the overall picture of where he was headed, what the team was headed and the expectations of the company. Second, I had already been looking at joining up with a couple of friends to begin our own consulting firm. My old boss and his boss. Well, the way he approached me on the move, sealed the deal. Within a month, I was gone and the 3 of us began building a successful consulting firm.

I don’t know if the cards would have been played differently if he had spent more time with me during those 7 months. If I had gotten to know him better and he had sold me on his vision, the overall company vision, I might have reacted differently and ended up out on the East Coast. Hindsight being 20/20, I’m ultimately glad that I stayed in Iowa. I often wonder how many other people this guy lost because he didn’t know how to build relationships and connect with the people who worked for him. I have also never been able to figure out how he managed to become a VP.

Our willingness and ability to communicate can solve the challenges we face on a daily basis. I’m constantly telling people, get out of your chair, go find the person you need and have a discussion. Don’t wait! If they’re not in the same building, ping them via our IM tool or video conference them in for a conversation. Take 15 minutes today, will save us hours/days/weeks down the road vs letting something get thru and then having to back up and do a total redesign.

If you'd like more information on my background: LinkedIn Profile

Bosses - One Flew Over The Cuckoo's Nest!

Bosses can be interesting people – I say that tongue in cheek knowing that this is a role I’ve now played for the vast majority of my career. Some bosses teach you what to do, other bosses teach you what not to do. This memory is going to reflect on things I learned not to do after one particularly interesting boss.

In one of my roles I ended up working for a great team. I really mean this, I loved the people and spent a lot of time with them outside of work. Anything from getting together for drinks, to grilling out to playing on rec sports teams. We all enjoyed being around each other. We celebrated life’s successes with each other and we were there for each other in the difficult moments of life. These were great people, they really did care and they weren’t afraid to show it.

Due to nature of our personal relationships, it made work a lot easier. We were all comfortable with each other and it allowed us to not only get a lot of work done together, but to have fun while we were doing it. Practical jokes were played in and out of the office, nothing disruptive, but enough to let the target know that they had been had! I got stung more than once by these friends, and we still laugh about it to this day. I don’t really recall there being a lot of formality in the office, you could approach anyone with an issue and count on them to help you push thru it and find an answer. There are many times I’ve thought about being back with that group of friends/team mates. Everyone, except ‘The boss’.

‘The boss’ wasn’t my official boss, but effectively ran the place. The owner lived out of town and ‘The boss’ had official free reign across the entire organization. ‘The boss’ was also disruptive! Promises were made to customers without ever checking internally to see if it could be done or when it could be done. Decisions were made without any input and without any reason, sometimes reversing the decisions that were made the prior week. ‘The boss’ would play people in the office off against each other. While I was not an official direct report of ‘The boss’, I ended up in many meetings to discuss customer issues, project issues and what was being done to resolve said issues.

These meetings typically devolved into shouting matches, with the end result being who could yell the loudest, the longest and wear the other side down. Or ‘The boss’ would make demeaning statements about your ability to do your job’ To say it was stressful would be an understatement. You would walk out of some of those meetings completely mentally and physically worn out. You never knew when these meetings would occur, your day could be going well and boom – you get called into a meeting with ‘The boss’. There goes the day!

You always knew when ‘The boss’ was back in the office, suddenly office doors closed and the attitudes of everyone changed to sullen and silent. This was no way live and work.

After a couple of years of this insanity, I decided that it was time to move on, working in that environment was not how I wanted to live my life. While I loved the people, ‘The boss’ made it untenable. It was weird, I was on a business trip with a peer taking phone interviews and trying to figure out how to ‘hide it’ so that he wouldn’t know what I was doing. It was toward the end of the trip when we both figured out that each of us were doing the same thing.

While I was glad to get out of that experience, I also look back and realize what I gained out of the experience. I learned a lot of things that I tucked away as examples of how not to treat people:

1. It is not ok to yell at people in the work place.
2. It is not ok to promise customers stuff when you haven’t reviewed with your internal teams and have no clue what you are promising.
3. It is not ok to schedule multi-hour meetings with the express purpose of just using the meeting to wear your opponents down just because you can.
4. It is not ok to jerk your team around with ping-pong decisions that can’t be explained.
5. It is not ok to belittle people in front of their peers.

I probably learned a lot more during that experience than I’m remembering at this moment in time. I left because it was the right thing for me to do. I miss the daily interaction with the friends I made, but do not miss the insanity of the situation.

I will forever remember the day I got word that I was selected for one of the jobs I’d been applying and interviewing for, that finally would allow me to get out of the situation – I had been in a meeting that lasted the entire day. ‘The boss’ was in fine form and it was a true death match between development and ‘The boss’. I didn’t say much the entire day as the head of development took the brunt of the heat that washed across the room. That said, the end of the day hit and I was completely spent. I drove home wondering how much more I was going to be able to take.

When I arrived home, my wife asked me what was going on and I started to describe the day – in brutal detail. Part way thru the conversation, the phone rang, I looked at my wife and told her that it was probably ‘The boss’ and to tell her I wasn’t home. My wife answered the phone and told me that I needed to take the call as it was one of the companies I’d been interviewing with. I sat on the phone as the job was offered to me and didn’t hesitate to say yes when asked if I wanted the job. The funny thing, when I handed in my resignation, ‘The boss’ tried to get me to stay. Didn’t happen!

What have you learned from your bosses along the way?

If you'd like more information on my background: LinkedIn Profile

Reaching Out ... It's Your Job!

What are you doing to help someone find their way?

Last night, I had the opportunity to attend our local school board meeting and to be part of a presentation for a program titled: Tech Journey. This presentation was to inform our local board of actions that the district had taken over the summer to provide students with the opportunity to explore, in a hands on environment, careers related to technology. This effort was focused on letting 8th grade students have experiences that could impact their education choices and potentially open up opportunities for them to explore career choices. Better yet, the program was focused on providing these opportunities to students who typically don't have a lot of resources available to them on regular basis.

I commend the district administrative staff, the instructors and their technology team for leaning in on this effort and making it happen. Tech Journey was originally envisioned by a team of people in the Des Moines School District, and the Johnston School District was able to work with the original Tech Journey team to construct a similar opportunity for kids within our local district. A win for everyone involved!

So how do I fit into the picture and why was I at the board meeting? Well, for years, I have been working with several of the local high schools. I go in and talk to the students about what it's like to work in technology fields, I work to find volunteers to help the students in programming/security competitions and I work with the administration in helping to define programs that give students an opportunity to explore technology opportunities. I also do this with some of the local colleges and across both high school and college students, I provide internship opportunities when their is a good match between a students experience and opportunities that I have in my teams. Yes, most of these internships go to 2 or 4 year college students, but when the right high school student comes along, we work to see if there is a 'right' fit. My job last night was to support the district staff in the presentation and show the commitment to this particular private/public partnership to help students.

Early this spring, I was contacted by the administration team planning the Tech Journey event and asked to review the curriculum and then to see if I could find the necessary volunteers to work with the students. Working with the team, we refined the standard Tech Journey schedule and curriculum. I was then able to find volunteers within my team to work with the students and explore the following:

1. 3D Modeling using SketchUp
2. Programming using Scratch

Next year, the district hopes to expand the program to include basic HTML and CSS concepts.
For the 3D modeling, the students all got to use a tool called SketchUp to create Lego like blocks. This took the better part of the morning as they took measurements and then learned how to use SketchUp to create the actual 3D model. The technology team from the district, had setup 3D printers and over the lunch hour then printed each students block. The final test, would the blocks fit together? Why, yes, they did!

The afternoon, was split into 2 different sessions. First the students got to experience Scratch - programming for beginners. They had a lot of fun working to create a game, guided by some of the volunteers, Students were able to work in a casual manner with 1-on-1 interaction with the volunteers. The 2nd part of the afternoon was a Virtual Reality experience.

I can only hope that these young minds walked away from the day with the knowledge that they have the capability to do this type of work. That it is not intimidating.

I know that my team had a lot of fun working with the students that day. Between the different sessions we had Sphero competitions between the students and the volunteers and at the end of the day, everyone was able to partake in a Virtual Reality experience. I gotta say, the technology available to students these days is impressive! My team is now asking to get VR equipment - not sure how I justify that!

So, why am I writing about this? A couple of reasons come to mind. 

First, all of us have a responsibility to find a way to help the next generation take their first steps. I'm truly passionate about working with students across middle school, high school and college to show them what opportunities exist and why they should be interested in pursuing careers in technology. I want to share my experiences, as a way to show to others that there is not a large investment of time, and that the rewards far outweigh the time spent volunteering.

Second, I want to encourage my peers to find a way to help students explore these careers. We all know there is a shortage of talented team members in the technology field - I don't care which field, there is a shortage and it is going to get worse before it gets better. We need to find ways to let young women and young men know that they can succeed in this field. If only one of you reads this article and then finds a way to volunteer to help a group of students or an individual student explore technology as a career choice, then I'll call it a success.

Maybe it's your own student, maybe you find a day to volunteer at your local school, maybe you help a group of students compete in a technology challenge. Only you know what you're capable of and what time you have available to help these students. Find a way! Be a part of something bigger than the day to day grind!

If you'd like more information on my background: LinkedIn Profile

Walking thru the Fire!

We’ve all been there. The day is going smoothly. Until it isn’t! Without warning, something happens and you find yourself with flames reaching up around you and the pressure mounts. It’s at this moment when you find out the true character of the team you work with. I’m not just referencing the people that either report directly or indirectly thru you, but your peers, team members across the organization that engage in the resolution of the issue or create the communication strategy, and the leadership team.

I continue to be amazed at the team that I am lucky enough to be a part of every single day! We’ve recently had some issues pop up unexpectedly and it pure pleasure to watch these folks in action. Like any other organization, we have our fair share of challenges communicating with each other, getting decisions made in a timely manner or with projects hitting hurdles that they shouldn’t hit. If everything ran perfectly, there’d be no need to any of us to do our jobs. Right?

Most recently we had a production issue pop up – yes, it does happen. Anyhow, this issue wasn’t a burn down the house issue, but it was still important and it did have impact. My job is to engage and clear the deck where I can for the folks actually having to work the problem, provide a framework for the decision process, to ensure that the team is putting logical steps in place to validate the resolution and to ensure communication up to our executive team.

I’ve always respected how this team responds to production level issues. Without needing to be told, people assemble together, open up a conference line and the artificial walls that exist on a day to day basis disappear as people work the issue. In this particular instance, the folks involved had commandeered a spot around one of our engineers where people involved in the issue had congregated – sometimes we grab a conference room, sometimes we just pull together around a desk and work the issue. This day, it was the informal – people floating in and out of the group as needed to work the problem, troubleshooting the issue, and moving the ball forward. During the day we had developers, leads, Unix engineers, Unix admins, architects, database analysts and management members floating in and out of the conversation depending on what was needed to either walk thru what was known, replicate the issue and ultimately to find a reasonable resolution to the issue.

Nobody panicked, everyone felt comfortable challenging statements that were being made and checking individuals to ensure that the thought process was valid. Nobody took those discussions as personal challenges, everyone was working to ensure that we found a resolution to the real problem. I won’t lie, we chased down a few rabbit holes and had to back out before we ultimately found the real culprit and were able to truly solve the problem.

I love this team! They not only challenge each other to be the best, but they challenge me to be my best.

If you'd like more information on my background: LinkedIn Profile

Accountability ... It's For Everyone!

Accountability: the state of being accountable, liable, or answerable.

Software Engineering is as much art as it is engineering. From the engineering side, their are best practices that guide developers on how to structure code, ensure the contracts between functional silos are maintained, ensuring performance constraints are adhered to, etc. On the creative side, there are a million different ways to write a specific function, as code is created, the engineer has the ability to choose how the exact implementation will be constructed.

From a management perspective, it can be hard to set and ensure that our teams are on track with specific milestones. Over the years I have tried several different tactics. Some have worked better than others. Recently, I've come to believe and rely on the following as a way to ensure that the leaders within my team have a pulse on what is going on within their teams and can actually provide factual responses to the question of 'where are we at'.

First, we established daily stand-ups within each of the resource teams. These run separate from any project related meetings/stand-ups that the project managers may run. Our goals with this 15 minute activity are to:

1. Open up communication within each of the respective teams and let every team member have visibility into what is happening.
2. Ensure that there is accountability within the team - everyone knows what the promise is and has to speak to what they've accomplished and what is coming up next.
3. Give the leaders of each team insight into current tactical activity to ensure that team members are working on what they are supposed to be working on, eliminating unplanned work, shifting resources to address roadblocks, and validating that the appropriate progress is being made to meet the established milestones.

These meetings run quickly - typically 15-20 minutes and each team member goes thru the following items:

1. What did I accomplish yesterday - was I able to deliver on what I promised.
2. What roadblocks am I encountering - do I have a path forward or do I need assistance.
3. What is my promise for tomorrow.

I am not able to attend every stand-up for every team, but I like what I'm seeing within these meetings. Team members are engaging with each other and have a better understanding of what all is being worked on within the team. When there is a problem, people are offering to jump in and help resolve the issue. When people have a little bit of down time, they are volunteering in the meeting to help other team members out with their tasks or are jumping ahead on stuff that still needs to be done.

These simple questions and setting aside 20 minutes a day to discuss, has altered how we are handling things within the team. First, I believe we have significantly reduced the unplanned work. Second, we have much better visibility into when a team member might be stuck and people are jumping in to help - either by just talking things thru or actually getting on the keyboard and solving issues. More importantly, I would also argue that my teams are communicating better. Communication is the key to everything, if we talk with each other, we solve problems and create wins!

If you'd like more information on my background: LinkedIn Profile

Be the change, don't wait for change!

Let me walk down memory lane for a few moments. My first formal job in the technology field was actually not doing software development, but was in sales and training. I sold IBM PCs, Compaq Computers and System 36’s. I was also expected to teach courses for the store that I worked for – Lotus 1-2-3 and dBase III. For those of you with memories going back that far, yes, I’ve dated myself. I would venture to state that most of the team that work with today, would have no clue what a Compaq luggable computer was nor even understand what an IBM Baby 36 looked like.

I sold computers for a year before I found a company that would hire me as a developer. While I did well with the sales aspect of it, I knew that selling was not my cup of tea and was not something that I wanted to pursue as a lifelong career. Getting that first development job felt right. Ok, I had been doing contracting since I was a teen, so this was really just coming home to what I knew I was meant to do. Pounding out code was comfortable, solving problems gave me a rush and was what really fed my soul. It was good to know what I wanted and then to find a company actually willing to let me pursue my passion.

I was hired to come in and develop software using Clipper (this was a compiled version of dBase III). Creating financial solutions for a very specific industry. I learned a lot in that first professional development role. How to truly plan for and test code – testing was not an afterthought, but something that was worked on just a diligently thru the development process as was the actual coding. I learned how to work on a team – understanding the role of the people creating the requirements, performing user testing, performing QA testing and then having to package up and deliver the code. Team also meant working with other development engineers to ensure that the stuff I was building fit with the stuff that they were building. When I was doing contracting, I was a one man show and did not truly appreciate the interactions needed to fit my stuff in with the work everyone else was performing.

Over the years I have had to learn and use several languages. In middle school and high school I formally took a Fortran course and taught myself how to code in basic. I can’t remember if I took Cobol or Assembler as a class, but I know by the end of high school, I could use both of those languages. Assembler was not something I enjoyed, but I could do it. I had also learned how to program using Basic. So, by the ripe old age of 18 I was able to hack around with 4 separate languages. College reinforced Assembler and added Pascal into the mix, along with several different theory courses. While I was acting as a sales rep, I was able to have access to a Compaq luggable and during the evenings I was able to teach myself Turbo Pascal. I also taught myself dBase III and was able to get a hold of the Clipper compiler and teach myself how to use that to compile the dBase III programs I was creating. Since then, I’ve taught myself additional development skills – C, C++, MS Visual Basic, CA Visual Objects, Java, Python, Ruby, Ruby on Rails, JavaScript, PHP, Objective C, Swift and others. I’ve also figured out how to use HTML, CSS and other web tools. This doesn’t include all the frameworks that I’ve learned along the way. I will be the first to admit that I’m not an expert in most of the previously mentioned languages, but I at a minimum can hack my way thru a development session using the languages mentioned above.

Why am I listing off all this stuff? Well a couple of reasons:

1)      Lifelong learning is critical within the technology arena. Those who think that they can learn 1 or 2 things and use that their entire career are in for a world of hurt. I would say over the last 30 years, the pace of change and expectations of picking up different development skills has accelerated – much the same as in other professions. Today’s focus on DevOps and other paradigm shifts, is forcing developers to learn new skills and become even more adaptable.

2)      There is a tendency to ‘get comfortable’ and develop new code using technology that you are familiar with – you can get it done quicker! However, at least in my organization, I sometimes need/desire to have people jump between teams and this requires that they be able to utilize different technology skills – C++ vs Java vs Objective C, with a little Python thrown in here and there to make things interesting.

When I first started programming there was no internet, no on-line help, no instant messaging to help me figure out how to get around different programming problems. There were thick manuals that I had to sit back and read. Today, engineering teams can use the internet to find solutions to problems, to find sample code or entire libraries/code that solve the particular problems that they encounter.

I remember having to write my first authentication and control system to wrap around a system. Today, I can go out to git and find dozens of complete libraries that perform basic application authentication to complete 2FA and access control within applications.

The tools available today make it much easier for developers to gain a basic proficiency of a given language. You can find on-line tutorials that guide you thru downloading a new language, creating your first project and stepping you thru the ins and outs of the frameworks. I would have killed to have access to those types of tools as I was starting to develop software.

As software engineers, we shouldn’t be afraid to pick up new skills. As leaders, we should be encouraging our team members to take a look at the new languages, scripting languages and frameworks. We should all be looking at ways to increase our efficiency, deliver functionality faster, increase the quality of what it is we are building and keep an eye on emerging trends that may impact the systems we create and support.

If you'd like more information on my background: LinkedIn Profile