The Software Engineer with Golden Handcuffs
How to save your soul from a soul-sucking job
Upon opening the garage, I was hit with the blast of arctic air that just dumped three feet of glorious snow on the Maryland area. I began my overly-generous neighborly task of firing up the ATV with the Snowplow. I did this as an annual exercise to help plow our neighborhood's private lane. This was about a quarter mile long. My neighbors had no clue or ability to help, these would be the people that would be the first eaten by the Zombie apocalypse. One year, my neighbor offered to have his friend help plow. His friend had a truck with a plow. I said sure. Appreciate it since I hated doing it for other unappreciative neighbors. Being who I am, I became skeptical about the ability of my neighbor's friend ability to deliver. As the snow accumulated, even IU knew that a truck can only push so much snow before becoming beached, or worse yet, burning out a transmission. Well, guess what, I was right. He burnt out his transmission and would not be able to help. I am a genius that way in predicting events. So, not only was I unable to keep up on the snowfall by repeated plowing, I was now faced with 3 feet of snow. Thanks, loser neighbor. So, I get out the 24inch snow blower and start to make a dent. I am a trooper. Hours later, I am now able to use the ATV with the snowplow to clean up the remnants of the blizzard of 2016. Being exhausted, I figured the neighbors would be able to handle the clearing of their driveways and the common lane that went past my house. Was I wrong yet again? I bailed them out with my snow blower and ATV. It was an ordeal and I could have stayed inside all nice and warm playing with the kids.
For me, life became mundane and boring. I lived in Maryland where you can live in a neighborhood for fifteen years and not even know your neighbors, let alone, get them to wave back to you. Honestly, it was that bad. I attribute most of this to them being introverts that worked at the NSA. They were people that walked down the mile-long hallways staring at the floor. An extrovert at NSA is someone that stares at someone else shoes. It was so bad there, that the cafeteria had 'Enter' and 'Exit' signs above the entrance doors to guide the flow of the crowd. Well, the introverts typically ran into each other since they never looked up. In retrospect, this is how some of the introverts were able to socialize and get married and have offspring. Well, these were the people that lived in my neighborhood. Lucky me. And I was the nice shmuck that plowed them out each winter.
The only benefit to living in Maryland was that I was a highly overpaid contractor. I had the Golden Handcuffs and did not worry about money. It was the typical life lesson, M=money over happiness. How to save my soul before it was too late. I tried a few side business, but these were not as exciting as I had hoped. Although one was very successful which I why I am semi-retired right now. So, sitting in a crappy cube, working for mindless people was just not working for me. My immediate coworkers and company were great. They were the exception. The rest of the people there just did not get it.
So, to start taking care of myself, I took the family on Royal Carribean cruises. We got away from the snow and cold and soulless people for all but a brief moment. Mass depression set in when I would have to return to the office. I think mainly because there was no sense of purpose where I worked and the majority of people were just waiting to retire -- umm, in thirty years.
A 2016 cruise took us to Key West as a port-of-call. It was fun and a nice town in the middle of the ocean. I thought, why not see if I can work here. So I foolishly reached out to a woman I worked with in the past. In hindsight, this was a mistake. I should have worked with my current company at the time to see what they could do to get me work in Key West. So, Jovian Concepts was my Titanic. I foolishly thought they would be as good as my current company. I was wrong. I immediately received a weird vibe from the small company and the lady that found a position for me. Note the position was vacant for over a year, so she did not have to work too hard. If at all. Lesson one, be cautious when people act like they are doing you a huge favor. Run away.
Anyway, I am venting and am amazed crappy company's like this still get work. I made a huge career mistake going to them and now tell everyone to do their due diligence before talking with this or any company. So, the lesson is, the grass is always greener. Go with your gut feeling, if it does not feel right. Run away from the deal. Always keep searching for something you love doing and surround yourself with people that can help you and not bring you down. They do exist and when you find them, stay with them.
How I Use the Atlassian Suite for Software Development
As a Software Engineer, I always resisted using management tools to perform my tasks. I did fight the process and worked to just get the job done to the best of my ability. I often succeeded and my reputation as a senior, 'Gets shit done' engineer benefited. This all worked fine when I worked on my own tasks, but when I started working with a larger team I dealt with system engineers and with program managers that were unqualified. These types would do drive-by tasking without realizing they were the problem. They did not understand the Software Process. It was embarrassing and they brought productivity to screeching halt and destroyed morale.
So, in order to manage these manager type, I quickly realized that software process tools were a benefit to me. So, to defeat a typical incoherent driveby, I would say, is it in JIRA? is it assigned? and better yet, has it been tested. Of which, the systems engineer would run away not knowing how to properly create test plans or test a system before deploying to operations. In the defense contracting world, they hire anyone with a pulse and the good ones leave or are forced out. But I digress.
Once I started playing with the Atlassian Suite of tools I quickly saw the benefit of these tools to the software development process. These tools are well thought out and improve the day-to-day workflow of the Software Engineer. First off, simply using Git/BitBucket is critical to any software development effort. I would create my project, upload my files into a Master branch or Gold Copy Branch. From here I would create a Development branch from which all JIRA issues would be branched. With this, I created a Release branch that was a place where resolved JIRA software issues were pushed for Integration and testing and combined with other issues to form a release. Once finalized and approved the release would be Tagged and pushed to the Master branch. The Tagging is critical since it allows you to pull from Git using the tag. With Atlassian, you can also view work history and control the merging of branches into the development branch once code/peer reviews were completed. You could also see a history of all commits and who performed them. I had the most commits and branches created since I was the most productive person at my last sad government contracting position. This was a place where mediocrity was deemed as awesome. Such a sad place and I hated it and the company I worked for, for many reasons. But that is another story about following your gut and who to trust.
So, having addressed the benefits of git for software source control management, I want to mention the next process of creating and tracking issues using JIRA. JIRA allows you to create new issues and categorizes them as new tasks, bug fixes, enhancements, etc. It allows you to establish a historical workflow of the issue so all can follow the progress. This removes all guessing as to what is being worked on and the status of the work. JIRA issues can be prioritized, assigned to team members and categorized into existing JIRA Epics for the project. You can organize this shit to death and it is a very powerful organizational tool for your software development process. This says alot coming from me that used to be a cowboy code slinger that just got shit done. The addition of this process was not oppressive. And as mentioned, helped me managed the idiots that thought the understood the software process.
Now enter the SPRINT planning. With JIRA issues created and placed on a queue, or backlog. The Sprint can be created. Typically done in two weeks spins. You pull the JIRA issues you want to be part of the sprint and assign, prioritize and estimate the work units or hours required to complete the issue. Bam, then you start the Sprint. During the sprint the team can update the status of the issues and move them from assigned to started and in progress to completed. At the end of the sprint you can see how well the team did with the number of issues completed and the metrics on their allocated work units. If you ware way off on the sprint and your progress, you can readjust for the next sprint or identify that you need more resources to meet the sprint deadlines. This process keeps the team marching in the same direction.
Now one of the coolest features is the Kanban board.
Kanban board swimlanes identify bottlenecks in your workflow.
Now to tie the entire software process together and to incorporate the overall project concept and requirements, we use Confluence.
Initially, I used Confluence for creating and organizing design documents and software development notes. I also created forms and templates to aid in my daily workflow. You can create process workflow templates and have these instantiated for each iteration or release. These then become a record of your testing, or lack thereof on my project and your deployments and collaboration efforts with other teams. As the team started to see the benefit of these Atlassian tools to aid in our daily workflow and program management, I decided we needed to capture the requirements as well. I know, what a concept. They were currently kept in an antiquated app on another system and the requirements keepers became combative when asked to add these to Confluence. So, being the resourceful engineer that I am. I took a new task, entered in the high-level requirement and derived sub-requirements. This was easy to do using the requirements plugin located in Confluence. Once I got the hang of this, I quickly learned that once I had the requirements defined, I could create use case and expectations on the confluence requirements. What was even better is that I could create tasks and link these to existing JIRA issues or create new JIRA issues from these tasks. Now you have a complete end-to-end software program management process. For me, I saw the light and it made me a better person.
Having said all this, I approached the Atlassian tools with an open mind and learned how to incorporate these tools for my personal career growth. I was fighting an antiquated government and management mindset that New Things Are Scary (NTAS). In the end the team adopted these tools and talked about implementing what I did without even recognized I already experimented with this entire process and was following the proper software development process. For some reason, I was excluded from the software process discussions. It was an odd feeling being a Principal Engineer and not being included in software process discussions. At this time I new it was time to save my soul and escape from both the horrible government IT environment and from the cult that was my payroll service. Whew, my advice is to do the opposite of what I have done and you will be fine when it comes to career choices. But going through horrible experiences sometimes gets you rewards. I am now doing what I love and making alot more money too. But I digress. Definitely take my advice and use tools in your software development process. It honestly will make your daily work life go easier and keep you organized and your team marching in the same direction.
Why create a table when you can create a graph!
Exactly. So many GUIs, both Thick and web-based, use tables to represent data. Much like looking at a spreadsheet. Very hard for an end user or analyst to detect patterns, trends, anomalies from looking at rows and columns on a spreadsheet. People are visual. Writing was introduced around 2600 B.C. https://en.wikipedia.org/wiki/History_of_writing. Humans are visual creatures. Most of us process information based on what we see. 65 percent of us are visual learners, according to the Social Science Research Network. https://www.forbes.com/sites/tjmccue/2013/01/08/what-is-an-infographic-and-ways-to-make-it-go-viral/#47ac58127272
Data is king. We all want data and want to be able to analyze what we are collecting. For many years, I have created graphical user interfaces for end-user operators and data analysts. Overwhelmingly these users ask for visuals to represent their data and to provide any alert type information. Even providing InfoGraphics to represent the data with both stats and graphs is very powerful.
D3 is very forgiving with the format of the data you provide. But I do my best to format the data set the way the D3 visuals request it via their examples. It is not that difficult once you get the hang of it and understand what the data format represents and how the D3 widget reads it and displays it. The cool part is that these D3 visuals are interactive. If you mouse-over a map, you can create events to highlight the state or county and provide detailed information by means of a balloon or other info panel. But this is just the basics. You can update your D3 visuals as data is received via asynchronous web sockets or simple pulling of data from the server side. I prefer serving the data from the server side to the clients via web sockets. This provides for a much richer and cleaner user experience.
Wisdom is the application of knowledge. Ok, so I can write about D3, but have I ever used it and deployed an application to the users? Well, Yes. Here are some of the applications I created using the D3 library:
- Spectrum Analyzer - providing sample data via Web Sockets.
- Map - Interactive Mercator map to replace deprecated Google Earth Plugin. Plot and edit Waypoints with meta info per waypoint. Redraw on map with pan and zoom.
- Force-directed graph - show data entity relationships. Helps to find info visually that is missed or that should be targeted.
- Series graphs showing many series on a graph to depict pattern of life and trend analysis.
Yes, it is true. If you want to make alot of money, consider becoming a Software Engineer with one of the many Defense Contractors in the Baltimore/Washington area. The golden ticket is your ability to obtain a Top Secret/SCI Full-scope with polygraph clearance. This is your Golden Ticket and will allow you to earn approximately $60k more a year than over a similar private sector position where you are competing with the H-1B Visa software programmers. This is what lowers what private companies are willing to pay you.
So, if you are clearable, start looking into working for a defense contractor. Note that not all contracting companies are the same. Contracting companies can be categorized as the following:
- Big-Box Companies acting as the Prime on the contract.
- Small subcontracting companies that sub to the primes.
Typically the Primes cannot staff the contracts they win, so they have partners that they allow to help staff the contracts as subcontractors.
Both Prime and subcontractors can be:
- mere body shops or
- 'Butts-in-Seats' type companies.
'Butts-in-Seats' is where a company will hire anyone that has a active clearance and puts the new hire on contract as a billable Full-Time Engineer (FTE) regardless of qualifications. There is the typical 80/20 rule where 80% of the engineers on contract are not needed, are redundant or just plane do not work and watch YouTube or read Facebook all day.
The real bit of advice is to know someone that already works for one of these defense contractors and ask them about the company and contracts. I would steer clear of the larger 'big box' companies since you will not get paid well and you will be lost in the bureaucracy of a large corporation. Focus on the smaller companies. But be careful that they are not a 'butts'-in-seats' company that will place you on any contract and pay you as low as they can so they can pocket the difference. Be sure the company principals are billing. If they are on overhead, this means they need to take more money out of your hourly billable to pay for their existence.
Your day-to-day will require that you will work on site in government spaces. So, in effect, your company really becomes a payroll service since you do not sit in a company facility working with others in your company on a single product like an Apple or Google. In reality, you work in subpar government spaces with many different contractors and the government customer. You become assimilated into the government bureaucracy and processes. It is quite the experience and you lose a little bit of your soul each day.
So the key here is to choose a small company wisely, one where the principals are billable, empower you and are very transparent. A company where the team understands the game and understands that a good engineer wants to have fun and do great things at work -- not just sit at a desk billing. If the owners have Phds and tout their degrees, run away. These are folks that just do not get it and will waste your time as you try to create a better version of yourself. The one government agency I worked with was actually cutting all the PHd billet positions since they were deemed not essential. Once again proving the Software Engineer is the work horse of the defense contracting world.
So if you are able to get a security clearance, do not mind working in government spaces, and want to make alot of money, consider joining a small defense contracting company with the right ideology. I am being billed at $130/hour as a Principal Software Engineer. A DEVOPS coworker with a 2-year Associated degree is being paid $108/hour. Yes, America is great.
Do not use a recruiter to find you a position with a good defense contractor. They typical represent the body shop companies that do not pay well and have sub-par positions. Use Google to find small companies in your area. Send them an email with a cover letter on how you can bring value to their company. Small companies love eager, sincere and appreciative people and will go out of their way if they have a position that matches your goals.
Be forewarned, you will shake your head at all of the crap you have to deal with when working with the government and other contractors. Yes, you will learn from your team and it will make you a great and 'street smart' software engineer. In the end, it is all in what you define as being successful.
My definition of success is, Enjoying my work, supporting the mission, being challenged and being highly compensated for my hard work.
Mosquitos suck. I hate mosquitos and am trying to understand their purpose. Much like the purpose of Universities today and the insane expense of getting a Bachelors Degree in Computer Science. You attend school for four to five years, spending tens of thousands of dollars in tuition, books, beer and room and board. All with no guarantee that this piece of paper called a degree will get you a job. Let alone a job you like. If you are lucky to land a job, you immediately start off with a huge load of debt. If you would have taken that money and the years wasted in college and started a business or studied the technologies you cared about on your own, you would be well ahead of the game of life. The key things here are time, money and studying a technology for which you have a passion. In my years of college, I was forced to take useless classes like Chemistry, Spanish, and other no related core bullshit. I was naive and did not realize that college is just a business where you invest a shit load of money in a service with no guarantee for results from said service. I can honestly tell you that none of the courses in college were useful in my day-to-day life as a software engineer. Why? well, when you are hired, you are indoctrinated into the company culture and their processes. You learn their systems and coding methodologies. None of which universities know nor teach you. So, in retrospect, the purpose of the degree was to help get you in the door. Well, things may be changing and software companies are looking at people's abilities and not whether or not they have degrees.
Interview Coding Tests.
I have been applying to a few Remote Software Engineer positions that I see on StackOverflow Jobs, WeWorkRemotely.com and SkipTheRide.com. Some of the positions seem interesting so I apply just to see if I will pass their first-level of screening. Apparently, these remote positions are spammed with resumes so the companies will respond and have you take a coding test to weed people out. I get it, they are swamped and cannot interview 1000 people for one remote position. Here is my thoughts on this interview process.
As mentioned, I get it. The companies want to use the code puzzle as a filter to see who is really serious about the position. My concern is that a code puzzle is no real indication of how good a software engineer is at their trade. In today's world, you are mainly modeling data and using RESTful services passing JSON contracts to/from the GUI to the server side. I guarantee you, the skillset to do coding puzzles in not required in the day-to-day engineering world. The academics are sometimes good with this stuff, but these are the engineers that never know how to complete a task and deliver a project. This is based on my many years of experience.
The truth be told, these jobs that get listed on the tech trade sites are already filled via networking. They post the positions for legal reasons and to collect resumes for the future. The positions are over detailed and no one engineer can ever possibly have all the technical skillset to satisfy the billet. The core software skills I have noted below are what is needed.
So, for me. I suck at these coding puzzles. The most recent one was from iFit. They sent an auto email response instructing me to take two coding puzzles in under 30 minutes on my own time.
Thank you for applying to be part of our iFit Team! As part of our interview process, we first do quick code check. About this test:
You will solve 2 coding questions, which are fun puzzles to solve
Code in the language of your choice
These are logic questions and do not depend on any framework
There is a time limit of 30 minutes
You can complete these questions at any time, but preferably in the next couple days
To take this first interview phase at anytime, go to: http://hr.gs/ifit-mobile-interview
After you complete this test, we will analyze the results and determine whether we will do a team interview via a group video chat.
Best of luck!
The iFit Team
So I go to the HackerRank site and read the following:
HackerRank. "Solving code challenges is a great way to keep your skills sharp for interviews."
The article mentions that the serious industry tech leaders are like laughing at these interview quizzes and hoping more people ignore them. I blame Microsoft for starting this process. They needed to do this mainly since most of their engineer come from overseas and do not speak English, Hence why they can pay them $40k a year versus the $150k they should be making.
The real skills that I look for in a quality Software Engineer are the following:
A Polyglot or Generalist - Someone that can use the right tool for the job at hand. Not just spout off the latest tech stack buzz words.
Someone that has the ability to learn and knows where to look for solutions. Understanding the core concepts of software engineering are key. Using this understanding to learn and apply the appropriate tech stack to meet the requirements is crucial to the success of the project.
Easy going personality. No divas or no-it-alls. People that know they may not be the smartest person in the room and know when to listen and learn. As well as, politely help those that sincerely have questions or need your help working through a software issue.
A self starter.
There you have it. If you read a persons resume and their cover letter and hopefully know someone at your firm that knows them. Bingo, give them a call and ask them questions related to my bullet points above. You can most time detect someone that knows their stuff and one that can add value to your team and get the job done.
For me. I am compiling a database of all the companies that I encounter that use these coding puzzles in their interview process. I guarantee you that these are companies a quality software engineer would not want to work with. Sure, you may last a year, but you will be looking to get out since this is an indication of a culture that is not sustainable.
Companies that use coding quizzes and puzzles as an interview tactic:
(feel free to contribute to the list)