Opinion Archives - Page 9 of 12

February 13, 2018November 24, 2019

Professor Qualifications

I recently saw a job post for a computer programming instructor. The post required that the applicant have a masters degree as well as four years of professional experience. I was a little shocked by this. Does four years of experience in programming really qualify someone to teach others? To become a Master Electrician in New York takes a minimum of 7 and a half years of experience. To become a Master instructor in Taekwondo can easily take more than 10 years in most organizations. Mastery of most tasks takes a substantial amount of time – and programming is no different. To make it more difficult, programming projects tend to be long-term – often taking a year or more just for the initial release. This means that during a four year term of employment with a company, a programmer may only actually work on a very small number of projects. When I think of a teacher, I think of someone with a breadth and depth of knowledge on the task. Someone who has mastered all tasks associated with the subject they are teaching. But after four years, I don’t believe that any programmer could be said to be a master. In fact, in most organizations, titles like senior engineer would be reserved for developers with far more than four years of experience. Why does any of this matter? It matters because it shows part of the problem we have finding qualified programmers to fill positions. After all, how can we expect students coming out of our universities to have any meaningful skill in development if their instructors never ascended above the rank of junior developer? How can someone who never made any meaningful contributions to the architecture of an application mentor others on how to do so? Instructors should be those most qualified among our engineers who have spent decades writing code – men and women who can tell you about several languages, talk about the evolution of programming through their own personal experience, and talk about how they solved a wide variety of problems. Instructors should have a portfolio of applications and organizations they have impacted and understand software engineering, computer architecture, and all aspects of the software development lifecycle. If we settle for less in our teachers we are setting our students up for failure and ensuring that we will continue to see more tech jobs outsourced to countries that can do a better job educating the next generation of developers.

February 11, 2018February 11, 2018

Perfection Paralysis

A major problem with many projects is the quest for perfection. We don’t want to release a software application until it looks perfect, there are no bugs, it’s fast, and the user experience is flawless. And that’s a great ideal for any project. Unfortunately, the quest for perfection invariably adds scope-creep. What was originally deemed a good design is now less than perfect and requires tweaks. The performance is just not fast enough yet, so we’ll tune the servers. An executive decided there is a new piece of required functionality that simply must go in. On and on we go, and the app release is pushed back further and further. Projects can go on for a year or more before being released. Certainly we want solid software applications, but what does this quest for perfection bring us? In the end, very little of value. As release dates get pushed back, the customer begins to lose faith in the abilities of the development team to deliver. Increased time-to-market means we miss opportunities to sell our product. Increased release cycle times make us less responsive to user issues we didn’t see. These problems are among the issues solved by agile development. Frequently releasing code means that users can start getting essential functionality quicker, time-to-market is diminished, and teams can react to changing user requirements quickly. But to get there, we have to determine what the minimum viable product is and accept that things may not be perfect. We need to accept that our initial version will not be the best there is, but that it’s good enough to do what we set out to do. Understandably, this may feel uncomfortable to the perfectionist in us – after all, we want to give our absolute best. We want a product that we can be proud of and that the customer is dying to have. But if we wait, with delay after delay, we run the risk of having the best app that will never be used because someone else beat you to it.

February 9, 2018

Why Do I Write Code?

Today, I was read an article asking why you do whatever it is you do. If you are trying to sell to a customer, they’re not interested in what you sell but rather why you sell it. You may sell widgets, but people don’t buy widgets for the sake of having widgets – they buy widgets for whatever it is they do – the why. In my business, people don’t buy code – they don’t care about code. What they do care about is the why. Why do I write code? I write code to simplify business processes, to improve operational efficiency, to increase revenue, to ensure compliance with regulatory guidelines, and to simply make my client’s life easier. People buy those things! As a business, wouldn’t you pay for operational efficiency, increased revenue, and easier compliance management? Software can have an impact on every facet of a business and take your business to the next level. Don’t waste your time doing tasks that aren’t generating maximum revenue for your organization – find software solutions to solve those problems so you can spend your time having a real impact on your business by focusing your talents where they will generate the most revenue!

February 8, 2018

Finding Tech Jobs & Candidates

Scrolling through LinkedIn, I see people talking about how they can’t find jobs. Talking to companies, I hear how they can’t find qualified candidates. This seems to be the story all across the nation regarding IT positions. How can this be? Why are businesses unable to find candidates while there are candidates out there looking for jobs? As a software engineer and small business owner, I often look at job boards to see what companies are looking for, what trends are hot (based on something more than just twitter hype), and what direction the market is headed. Over the years, a few things have become apparent to me. First, software companies are constantly looking for employees that meet an absurd number of qualifications. Their requirements start to look like the checklist for a set of collectable cards. Is it really necessary for the candidate to be an expert in 15 different technologies? It’s particularly difficult now because of the sheer volume of technologies available for use. Languages, web servers, front-end toolkits, build environments, continuous integration environments, libraries, project management methodologies, and the list goes on. And under each of those categories, dozens of choices – C, C#, C++, Java, Scala, Python, PHP, etc. Eventually, job posts end up with so many requirements that you are literally looking for a needle in a haystack during your candidate search. Employers: Do you really need an expert in all those different technologies? I doubt it – you need a solid programmer who can learn the technology stack you have in place. The second thing I’ve observed over the years is that few developers actually have a drive to learn new technologies. How is it we still have programmers and other tech professionals that don’t know Linux? How can you be a software engineer and not have some knowledge of JavaScript? How many shops are using toolkits and frameworks that died years ago? Delphi is still out there, but would anybody actually chose to start a new project with this antiquated technology? Too many developers are stuck in their world – “I am a Java programmer, I use Eclipse on Windows, and I know Maven”. On both sides of the equation – companies and job candidates – there exists a real lack of desire to put in any meaningful effort. Companies could invest in their new employees and teach them the frameworks they need them to know. Just imagine the long-term benefit of showing employees that you care enough about them professionally to invest in them! Programmers could invest in themselves and learn new skills throughout their career instead of being content to use long-dead tech. Of course, neither side wants to invest any effort. So, companies end up without qualified candidates and programmers never go outside their comfort zone to learn new skills.

February 7, 2018February 7, 2018

Challenge Yourself

Today, I was reading some advice from Simon Sinek. He says we should always work to outdo ourselves. Don’t focus on others, don’t strive to be number 1, don’t compare yourselves to others, compare yourself to you. Are you making progress? This is great advice in the tech world as well as the business world. Sure, I can be disappointed that my company isn’t as big as Microsoft yet. Or I can compare where my business is today to where it was last year and ask if I’m making progress. If you are a programmer, is your code better today than it was a year ago? If you are a system administrator, are you better with Windows administration than you were a year ago? If you’re a network admin, do you understand Cisco routers better than last year? If the answer is no, why not? Unfortunately, too many people in the world today spend too little time advancing their skills. Then, when it comes time for a raise, they wonder why they didn’t receive what they expected. How do you make progress in the tech world? It’s actually not hard. Read books, see what people are posting on Twitter, write code (if you’re a programmer), attend conferences, tinker with new hardware, etc. Skill only comes with practice! I read someone else say that things are either green and growing or brown and dying. This is certainly true of skills. Use them or lose them. If you’re not advancing your tech skills, those skills will atrophy. If you want to achieve excellence in your field, challenge yourself to be better today than you were yesterday and then take action to ensure it happens!

February 1, 2018February 1, 2018

Management and Leadership

In the late 90’s, I attended the Army’s Primary Leadership Development Course, which was a requirement for promotion to Sergeant. This 4 week course included classes on leading physical fitness training, marching troops, compass and map reading (including a required night land navigation course), and other tasks necessary for leading soldiers in battle. Throughout the courses on leadership, the distinction between a leader and a manager was made clear. Of course, outside the military, I think most people would say they are synonyms. In the Army, leadership is defined as direct management of troops while management is indirect. What does this mean? It means that a leader directly interacts with his or her subordinates and a manager does not. A leader eats lunch with his team, a manager does not. A leader knows what’s going on in the lives of his team, a manager does not care. I don’t want to infer that management is in some way bad. We need managers – people in positions behind the scenes that move the wheels of an organization. But even more so, we need leaders. We need people who others aspire to be like, a person who inspires his team to great things, an individual that encourages others to be more than they currently are or even think they can become. For a leader, an individual will work extra hours, come in on Saturday, and end up being happy about it! In my entire career as a software engineer, I have found few people that meet these ideals. I’ve seen many managers, but few actual leaders. Indeed, in the software world we see titles like “Director”, or “Scrum Master” – neither one shows any sense of leadership. The title “Scrum Master” would never be chosen by a real leader because it suggests an incredible amount of superiority over the team. Leaders are part of what’s going on. They are doing what they tell others to do. They are protecting the members of their team. They are encouraging their team to do more. They are not above the action, they are an integral part of the action! Aren’t those the people you want to work for? The people you hope to be like? If you want employees to take your business to the next level, employees who are committed to your organization, empower them by ensuring the leaders you pick know how to lead – not just manage – those in their care.

January 29, 2018May 26, 2019

Retro Tech

In this age of tech, people marvel at artificial intelligence, robotics, smart watches, and the new iPhone. These things are all exciting, but some technologies of yesteryear are exciting in a whole different way. For example, it seems that record players are making a comeback. I would have never thought that! I remember when CDs came out – and who would ever want to go back to anything before that? Now, my daughter has a record player and I am absolutely spellbound by it. The thought of a ridiculously small trail of bumps on a piece of plastic that make sound is incredibly fascinating! What makes it more interesting to me, as a tech hacker, is that I can understand how it works. I could maybe even make my own with a servo and a few micro-controllers or maybe a Raspberry Pi. Much like gear heads who love classic cars because they can understand the hardware, the technology behind the record player is understandable to the average person. My favorite retro tech is probably the Nintendo. Not the Wii or the Switch – but the original Nintendo. I like the new Mario and Zelda games as much as any gamer can, but the original NES will always be my favorite. The simpler games that could be accomplished in an evening and didn’t require cheat sites and strategy guides sure were fun! Another interesting piece of yesterday is the Tandy 102 computer. A small laptop with an LCD screen and 4 AA batteries, it’s a piece of tech I still grab to tinker with sometimes. In fact, I’m getting ready to setup interface between the RS-232 port to an Arduino controller. Sure, the Tandy 102 only has 29K of “drive space”, but the built-in serial port and modem program makes it great for tinkering with hardware. I originally bought it to interface to a ham radio with a radio modem. I could take the handheld radio and the Tandy 102 up on top of the mountain and read a ham radio BBS or communicate with other hams in text modes. On of my current projects is building a replica Altair 8800 from a kit. Not the most practical, but I’m looking forward to tinkering with a replica of an older computer and gaining a better understanding of older computer architecture and software. When you’re looking at tech gadgets, don’t forget all those gems from the past! Some are still useful, some can provide educational opportunities, and most of them are just fun to experiment with!

January 28, 2018December 8, 2019

Bring Your A-Game

Recently, I was contacted by an individual leading a group of young engineers into a state-wide competition. This leader wanted to discuss the project and see if I had any advice. I provided him a simple improvement that would have greatly improved the product that the team was working to produce. Then, a few days later, I heard that he had decided not to take my advice. Instead, he would use my suggestion as an improvement if his team was selected to advance to round two of the competition. This really disappointed me. This leader has taught his team to try just hard enough – not to do your best. And, he made the mistake of assuming that his inferior product would advance to the next round. In today’s highly competitive market, this is the exact opposite of what the next generation needs to see. Instead, we need to install in those underneath us a quest for excellence – not mediocrity. If you can do better, why aren’t you? If you can make the product better, what’s stopping you? Innovation and excellence require pushing yourself every day – you can never settle for anything less. In everything you do, bring your A game. If you don’t, someone else will and you’ll be left on the sideline.

January 23, 2018

Planning & Execution

January is a month when people plan changes for their life. Some will change their diet, others will start exercising. I have decided to focus on setting and meeting my goals this year. Having a full-time job in addition to running my own business leaves little time to be wasted – so I really need to be intentional with how I spend my time in order to achieve my goals. In order to learn how to better achieve my goals, I have been reading books and watching videos online. One key point I see over and over in achieving goals is to take action. You can’t talk about what you’re going to do – you need too start doing it! This applies to anything in life – but today I was pondering how it applies to software development. If we want to release a piece of software, we have to start writing software. But here’s the problem – all too often is seems that too little time is spent planning how to write the software. We focus so intently on the end goal of releasing a software application that we ignore coding standards, fail to document code, avoid refactoring, etc. In the end, we meet the goal – but we end up with unmaintainable spaghetti code. So, while we may have met the goal, we end up ensuring that future development will take more time and be littered with potential problems. And, ironically, while we met the original goal, we could have likely released early if we had simply spent more time upfront planning direction of the code, determining good data models, etc. So, while inaction will paralyze any project, improper action will will end up being just as counter-productive.

January 22, 2018

Bad Teachers

Today, more and more tech realms require a bit of programming knowledge. If you’re a QA, you may be writing test cases in Python or Java. If you’re engaged in Devops, you may be writing scripts or code for automation or other tasks. If you’re a hardware hacker, you may be writing C++ code for an Arduino board or Python for interacting with GPIO pins on a Raspberry Pi. Unfortunately, most of the code written by QAs, devops teams, and hardware hackers is not up to the standards of good software engineering. Indeed, all of the above fields are more software hackers than real engineers in the software realm. What that means, is that when you view tutorials or documentation created by people skilled in areas outside of software engineering, that you’re likely learning poor coding standards. Of course, it’s seems hardly fair to hold QAs to the same standards as you do software engineers. But the problem comes later when the QAs say “I know Java.” Or when the hardware hacker says “I can program in C++.” Now, you end up with bad code entering your codebase because of untrained developers. I want to be clear – my point is not to discourage QAs and devops teams from programming. But rather to encourage developers to assist programmers in these fields to adopt proper coding standards. Treat there code with the same scrutiny you would a developer – subject it to code reviews, and demand proper coding standards. Otherwise, the same problems that plague software projects will end up causing problems in your devops environment or your QA testbed. Don’t assume that a QA can program in Java because they’ve written some test cases. After all, you wouldn’t trust me to replace the engine in your car just because I’ve changed the spark plugs in mine.