Which Programming Language Is Best? (Important Career Advice For Programmers and Developers)
by admin
Are you having trouble converting social media leads into paying customers? CoupSmart is an incredibly clever tool that lets you use coupon marketing with the “Insider’s Club” that is your social media contact list.
In addition to being the current CTO of CoupSmart, Troy Davis is an experienced developer with a long list of successes behind him. Through his years in the software industry, he’s noticed some key career trends that separate successful developers from the ones who never reach their potential.
Troy has been nice enough to sit down with me and share some of his insights. Enjoy the interview below.
Can you please give me a bit of background about yourself and CoupSmart?
I started out as a webmaster for ad agencies in 1995, worked as the software developer and default IT manager for a few companies as my career progressed. One product I worked on got some investment money in 2008 and I’ve been working for startup companies as CTO since then. I’ve concentrated mostly on Web applications most of my career, but have also developed a few desktop and embedded apps as well. In 2001 I started a group called the Cincinnati Programmers Guild, an educational non-profit that focused on broadening the knowledge of its members by endorsing no specific technologies, which is much different from most technical groups. Instead, the focus was placed on learning new ideas no matter what technologies were used. We had consistent monthly meetings for 5 or 6 years, and it was a great experience.
CoupSmart started in 2009 by CEO Blake Shipley. Originally centered around an iPhone app, we shifted focus at the end of last year to try some interesting ideas we came up with regarding the economic, business and social dynamics of coupons. We’ve been offering a Web/Facebook promotions system for a couple of months now, it allows people to share offers with their friends to earn a higher value offer. Our customers are mostly in Cincinnati at the moment. We’re focused on tying social media to the physical world for our customers, and have recently developed a hardware device for point of sale to assist in this effort. This is in beta testing with a few customers at the moment.
What is your biggest beef with mindset of the software development community?
It’s not so much the community of software developers that present a problem, most people who make the effort to seek out and talk with other programmers are seeking knowledge themselves, and usually want to learn how others meet their challenges. This often leads to trying multiple languages, vendors, platforms, etc. and that’s all good.
The problem I’m discussing is more often seen in solitary developers. The technologies they use are initially attractive simply because the job ads show higher starting salaries for developers with experience in them. After some classes and much trial and error, the developer becomes minimally competent in a narrow aspect of software development, and lands a job by interviewing (often) with a non-technical HR person that can’t screen developers well.
After a few years, the developer achieves a certain level of proficiency with the tasks often assigned to them, and are assumed to be software development professionals. And they often coast for however long they can at this level.
Some time later, a new person takes over the department and doesn’t care for the technologies used by their predecessor. So a migration effort begins, and everyone is expected to adapt to the new technologies quickly or find some other kind of work for themselves. If a developer had taken an interest in keeping up to date with their field of work, they’d have recommendations for the new systems to contribute, and would likely find a comfortable place in the new structure. But those who rested on their laurels often respond defensively, obstructing change because they simply fear it. And ultimately they get pink slips.
When I was active with the Cincinnati Programmers Guild, I saw many mainframe developers who had been laid off in waves, and once unemployed were desperate to pick up that one key idea they needed to get another job doing the same thing they were doing for the last 15 or 20 years. Many of these people came to their first Guild meetings having only written COBOL or Fortran their entire careers. They’d never bothered to learn anything else. And most of them seemed to have the idea that learning just one new language was all that they needed to regain their previous role and stature.
Some got certifications in .Net or Java, spending thousands of dollars to reboot their careers. A few got new jobs and I never saw them at Guild meetings again, they reverted to their solitary existences I suppose. But most of them lingered in unemployment for years, taking this class or that class as they could afford it with temp jobs. Very few of them tried to go freelance, either. They all wanted back into large companies, it seemed. The illusion of job security was prevalent, despite the obvious evidence to the contrary, meaning all of the people with similar career conundrums attending the meetings.
If a developer has had success under a certain platform or language, what’s wrong with specializing and becoming an expert in that particular area?
There’s nothing wrong with becoming an expert in a particular area of study, it’s overspecialization that’s the problem: Focusing on one set of technologies to the exclusion of all others. So just because you happen to like writing C++ on Linux doesn’t mean you should pretend like it’s the only way to write decent software. You might fool a few people into believing you, but ultimately you’re just fooling yourself.
An example: A programmer I used to work with just absolutely hated Windows and everything that went with it. Just couldn’t stand to be in the same room with it. I worked on a Mac, so I was exempt somehow. But we had a web application that needed to be compatible with all the major browsers, and that was the plan. This developer fought with just about everyone on the staff to simply not support Internet Explorer, which would have been an almost certain an act of suicide for any SaaS company. I was in charge of this group, so it was my job to try to persuade her to just get the compatibility work done despite her qualms. It didn’t work out very well, several fits of yelling and rage happened both in person and over the phone. I urged to work with her as a freelancer only for a while to see if some isolation would help, but it didn’t, and ultimately she was laid off.
Another example: A Linux developer worked with me at the first ad agency I worked at in the late 90s. He was young and very opinionated about how great his chosen technologies were. He frequently insulted coworkers for their technical incompetence as he saw it, he was not popular with the staff. But he wrote code nobody else at the company knew how to write at the time, and it was important code, so his social eruptions were tolerated. I decided to learn more about Linux and C at that point, and within a couple of months had a pretty good understanding of what this guy was doing every day. And it wasn’t much. His claims of technical superiority had become a crutch, and he used others’ lack of knowledge to justify not working very hard at all. Ultimately he was let go after a particularly nasty exchange with a few coworkers. The next day he logged into a client’s server from his home and deleted their entire website, along with several log files that might have implicated him in doing so. But he missed one, and it had an IP address, which we confirmed later that day with his ISP to be assigned to his login at that time. We lost the client anyway, but he got special oversight by law enforcement authorities for years afterward. Might still be monitored, I’m not sure.
Many would argue that it’s a smart bet and a smart career move to align your efforts with the strongest or most dominant platform. What’s wrong with this mindset?
Nothing, so long as you understand that what you’re focusing on is just the current flavor of the month, and will inevitably be replaced with some other technology at some point. So just be prepared by learning about the alternatives before it’s time to switch.
My point is that programming is a career path where any valued proficiency has an expiration date attached, and as time goes on, that expiration period grows shorter. This is commensurate with how fast hardware is changing, the microprocessor industry has stayed pretty close to the predictions of Moore’s law for over 30 years now, and many academics say that this is evidence that we are still in the infancy of computing. It would be unwise to assume that we’ve reached any kind of sustainable plateau with these technologies yet.
So the mainframe folks I mentioned earlier that had the same tasks for 15 or 20 years are likely to be the last of their kind. A lone, overspecialized programmer entering the field today may only get away with her current skill set for 5-10 years. This continual decrease in the longevity of newly learned computing skills agrees with the technological singularity concept, something that might be worth checking out:
http://en.wikipedia.org/wiki/Technological_singularity
What’s the worst that can happen? What’s wrong with sticking to techniques that are “good enough”, and more familiar?
I see possible dangers including a widespread deficit of capable programmers because of overspecialization in now-antiquated technologies (large companies have been using this claim to justify increasing numbers of tech worker visas for decades), and massive amounts of money spent unnecessarily to prop up an aging technology due to internal resistance to change. These ultimately make the entire economy less productive / profitable. That means fewer jobs for everyone and a smaller economy overall as valuable resources are spent in non-productive efforts, trying to catch tempests in cups of various sizes and compositions instead of inventing what’s actually needed for the foreseeable future.
And there’s a long-running developer philosophy that “good enough” techniques really are good enough, as long as you know your options well. That’s not at odds with the value of continual learning, however. Most of the time, “good enough” has to do with a judgement of how much time it would take to implement a more complex solution to a problem, versus choosing a simpler method which has known drawbacks, but will probably not manifest as a problem. Using an old technique to deliver desired functionality faster isn’t inherently wrong, it might be the best way to get the system working as desired. But being unaware of the alternatives for that decision can be costly for many more people than the developer and their employer. Software inadequacies get repeated over and over with growing numbers of people, so a bad decision of one developer can have a disproportionately large impact on the lives of many more people over time.
But more to the point, I don’t think it’s possible to back up a claim that any single software technology will be “good enough” to address a wide variety of problems over a long time span. We’re just not at that stage of technological development yet.
What was your development philosophy when working on CoupSmart, and what kind of results did it bring?
The software development work had already been started by two part-time developers when I joined CoupSmart, so the language had already been chosen, and it was PHP. It’s not my favorite language, but it’s perfectly suitable for modern web apps, so I wasn’t concerned. There’s also an advantage in that more developers fresh out of college have a working knowledge of PHP, whereas fewer are familiar with Ruby, which is the language I might have chosen if the variables had been different.
And although it’s probably too early to tell if our programming language choice had a direct impact on the success of CoupSmart as a company, we are often praised by other entrepreneurs in our circle of friends, their software development teams are working in .Net or Java, and are apparently far less productive given the same resources. So I’ll count that as a tentative win.
Why do you think other developers are so resistant to new ideas?
I think you can answer this with the same reasons people resist change in general. Fear of the unknown, self-doubt, overwhelming choices, etc. It’s really no different. We develop habits because it’s easier than rethinking every single past decision, it’s just faster. But when you fail to reevaluate your prior decisions for too long, there are always consequences as you and the rest of society drift apart ideologically.
One woman that I met through the Guild was a COBOL mainframe programmer who got laid off after over 20 years writing the same kind of code every work day. They replaced the mainframe with a more modern system, and she had not transferred to the team doing the new work. She thought their project would fail, apparently. It certainly could have, lots of software projects fail. But this one didn’t, and she was laid off shortly after the mainframe was decommissioned. She decided that what was so new in modern programming that had been absent in her work was object orientation (aka OO), a layer of abstraction that makes it easier to design large software systems. I encouraged her to learn a new language in order to become familiar with OO concepts, but she seemed afraid somehow. Months later, she told me that she had finally registered for a class in .Net. That would certainly cover OO topics, so I tried to give some positive reinforcement. But I think her conception of how novel this concept was may have gotten in her way of simply using it until she understood it. She remains out of work to this day, over 5 years later.
I’m acquainted with a developer who worked for a competing ad agency. I talked with him over lunch one time, and he admitted rather shyly that he was still doing most of his work in ColdFusion, a programming environment that is arguably not aging very well. I asked him if he was thinking about trying anything more modern for new projects, and he claimed to have investigated a few other options, but just wasn’t willing to give up his favorite environment, which he just loved and felt very comfortable with. About two years later, I heard that his company had shut down his department and laid him off, not enough clients wanted their work done in ColdFusion any more, and the developer just wasn’t willing to try something else, so they stopped getting new projects, and after a while they couldn’t justify keeping him full-time just for maintenance work on old apps.
