In one of the made-for-TV pseudo-histories of the Apollo program, an astronaut figured landing on the moon would be something like flying helicopters. So he learned to fly choppers. He didn't ask permission. His boss wasn't involved. No one told him to acquire this new skill. In the ultracompetitive astronaut office where spacemen vied for position, for that extra angle needed to get on a flight, astronauts took dynamic action to fill holes in their experience.
Wow. Yesterday I listened to a developer whine about his dead-end job, due (he claimed) to a slew of flaws in his boss. Actually, in a succession of bosses. His biggest skill is 8051 assembly language programming. He can't believe that the current boss wants him to move to C, which, of course, he doesn't know and refuses to learn. I was astonished to learn he's defiantly waiting for the company to send him to C class, using his lack of knowledge as some sort of self-defeating line in the sand.
Back in the old days, paternal corporations benevolently managed their employees' careers. You could leave college and work for IBM till you retired — and they'd take care of you. Need a new skill? Your boss would identify the weakness and schedule some sort of training.
No more. Today's existential competitive environment would make Kierkegaard gasp. At times it seems no one cares a whit for any individual. Cut costs! Drive up profits! Increase stock valuations! Get the product out the door today no matter what the personal cost may be. Joe is still struggling with C++? Replace the SOB! There's an army of applicants knocking at the door. The company has neither the time nor the incentive to engage in training and career management.
I believe it's our personal responsibility to upgrade our skills. Constantly. Relentlessly. Technology changes so fast, and even the first derivative of that change is accelerating. Too many developers stop learning when they leave college. Do that, and your career will end in your twenties. Companies will use your skills as long as they are still relevant and then spit you out, a burned-out husk, obsolete at 30.
In lectures I often tell firmware folks they must learn Watts Humphrey's Personal Software Process. It's one of many techniques sure to help reduce defects and improve estimating abilities. I push the PSP because it's something individual developers can do with zero buy-in from their boss or colleagues. Like a self-help program it requires nothing more than a personal commitment. Yet in follow-ups I find only a handful of folks ever work through the program. Many buy the book; few do the homework. The usual excuse (we're all busy and have very full lives) is full of truth but devoid of wisdom.
No doubt the astronauts have an incredible amount of personal freedom in their jobs, as well as a budget we can only dream of. They are all dynamic personalities who look at a problem, figure what resources might be needed, and immediately take action. That sounds like a great description of the engineering method.
Take action. Learn. Grow. Become expert at something new. Stasis in this industry is death.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at . His website is .
I think most engineers should upgrade their communication skills–grammar in particular.
Even in this article the author states “Technology changes so fast.”. “Fast” is an adjective. “Quickly” is an adverb. You should have said, “Technology changes so quickly.”
Nothing will guarantee you stay in your “dead-end engineering job” like not being able to communicate effectively with everyone else in your company.
James Morrison the Grammar Cop
Embedded Hardware Engineer
Hi Jack –
I just read your article “Just Do It” on Embedded.com. I want to convey some of my personal feelings on the subject. Although I do agree with you that engineers must maintain their own skills, I do believe that companies must also take on some responsibility. Engineer's fresh out of school are analogous to new cars, in that as soon as they accept a job, their skill-set begins to deprecate. Traditionally, a business would have a professional development budget to offer employees. You could consider this budget to be part of an employee's compensation package, above salary and stock options. I would argue that such a strategy is both beneficial to both the business and employee. Why? For a business, this means that employees are kept up-to-date on technology, resulting in innovation, lowering attrition and furthering the industry. For engineers, the benefit is obvious.
Engineers also spend a great deal of time at work. Engineers below the age of 30, from my experience, put in a great deal of time to the company. This is encouraged my management, who typically set unrealistic deadlines. The smaller the company, the more prevalent this phenomenon. If a company does not budget for training, engineers more than like will not learn newer technologies. Why? Because they are firstly too focused on their duties at the office, and secondly don't have the time. The only option for them not to get pigeon-holed is to accept a new job. Perhaps this is the reason for high turnover rates in this field. In my option, this issue increases dramatically with greater software abstraction. As a case study, consider engineers that develop with Microsoft technology. Take MFC as an example. Microsoft has provided a great deal of abstraction around GUI design, coupling engineers directly to their abstractions. So, as the abstractions change, so must e!ngineers. We all know that Microsoft changes its software layers maybe once every 5 years. Engineers can be completely replaced if a project moves between layers. I've seen this happen.
I'm not necessarily arguing that engineers do not need to accept responsibility for educating themselves. On the contrary, I believe that responsibility should be maintained on both sides. Businesses need to understand both the short-term and long-term benefits to training their staff. If they do not train, then an engineer needs to make sure s/he is being compensated appropriately.
I agree, self motivation is the way to be recognized and promoted. If you want time off to take classes, ASK. If you want time away from job tasks to learn a new language, ASK. Work something out with your employer. Asking and showing the desire to learn may get you that time off for study that you need. As a matter of fact, I took 7 credits of classes and cut my work hours back to 25 a week… it was like a vacation! Try it, you might like it.
Embedded Software Engineer
Here's what the folks who do the PSP training recommend for an approach to PSP.The second important step in PSP introduction is to train in groups or teams. When organizations ask for volunteers for PSP training, they get a sparse sprinkling of PSP skills that will generally have no impact on the performance of any project.
Third, effective PSP introduction requires strong management support. This, in turn, requires that management understand the PSP, know how to support their workers once they are trained, and regularly monitor their performance. Without proper management attention, many engineers gradually slip back into their old habits. The problem is that software engineers, like most professionals, find it difficult to consistently do disciplined work when nobody notices or cares. Software engineers need regular coaching and support to sustain high levels of personal performance.
The final issue is that even when a team of engineers are all PSP trained and properly supported, they still have to figure out how to combine their personal processes into an overall team process. We have found this to be a problem even at higher CMM levels. These are the reasons we are developing the Team Software ProcessSM (TSPSM).
Based on personal experience I'm 100% in agreement with all of the above. As a personal example, if one engineer teaches themself PSP, and uses PSP to come up with realistic estimates for tasks, but management chooses to believe another engineer who consistently badly underestimates tasks due to lack of PSP, then the team will be nothing but late, demoralized, and dis-satisfied with quality, management, and working conditions. The company may lose bonuses or other contract payments due to the bad estimates, or other credibility due to poor initial quality.
(To just be a software person that knows PSP is like being on a pogo stick — to get some stability the legs of team support, and management support need to be added)