1. The User is the Most Important Thing
2. If You Don’t Evolve, You’ll Die
3. Using OOP, Design Patterns, Frameworks, and TDD with the Right IDE Will Solve All Your Problems
4. You Can Code Something Right The First Time
5. There is a Clearly Defined Career Path in Programming

1. The User is the Most Important Thing

Making money is the most important thing.

Anyone who says the user is the most important thing hasn’t been in enterprise software, is endeavoring to fight against bad software, doesn’t run a business, or is talking about Open Source.

If you want good software, yes, you should pay attention to the user. Doing informal user testing, engaging with real users/customers while developing the software should be done. Investing in design early, heavily, and constantly are great ways to lead to building software that has a great user experience that people want to use.

That doesn’t implicitly make software magically sell itself. For mid-size to larger companies, those using the software aren’t the ones who pay for it. Often they’ll never use it, nor see it. They’ll be looking for the right marketing messages, and/or validation that it solves key problems THEY are concerned about. They are hoping to solve what they perceive as important problems to their business, not those actually using the software in their day to day jobs for their business.

A lot of the most profitable software is the most tortuous to use. Case in point, SAP. Atrocious user experience. Yet, it sells extremely well (well, did, heh, read Blue Ocean Strategy). SAP can “run your entire business”. No other software product can make that claim with that much history to validate the claim.

This is important when you consider extremely large companies with a variety of different departments from HR to shipping, to finance, to IT. Even a modicum of perceived productivity enhancements across the board implies a significant amount of money saved. Remember, the 3 ways to make more money in a business:

1. Raise your prices
2. Increase your output
3. Lower your overhead

If something can “run your entire X” where X is “your business”, “your IT hardware & software operations”, or “patient scheduling for 3 hospitals”, those signing the check are doing so because they perceive #2 and #3 improved. That’s what writes the check to your company building the software, not the nurses who use the software for patient scheduling and loathe the interface. Who cares if they do, as long as people keep buying it, it’s profitable.

Like TRON, I too fight for the User. If you want to build software that’s a pleasure to use, you must focus on the user. Life is too short to produce crap merely for capitalistic gain. Many companies build pleasurable user experiences and are profitable, from 37Signals to Apple.

Just remember making money is the most important thing. The happy user is not an implied gateway to bling.

2. If You Don’t Evolve, You’ll Die

You can learn 1 language on 1 platform on 1 OS, and remain employed with no worries, or get a new job if you need one.

Those insecure about their own career and investment in a particular technology stack project this line a lot. They do it in a variety of ways such as saying it as a factual proclamation for dramatic affect, as an ominous warning, or as a matter of fact statement that is law. Technical journalists creating click bait do this as well.

I’ve been employed & done consulting at enough places to tell this is completely wrong.

Some facts:

1. 80% of the world runs on a 50 year old language, COBOL .
2. AT&T still uses Fortran for some of their dialing services.
3. Although we’re in a tech hiring bubble, university/college enrollment in tech has continued to decline.

Business Insider has 2 good bullet points at the end of their hiring article which explains the problem well.

…skilled labor simply can’t change overnight. You can’t become a top-notch programmer overnight, and becoming skilled and proven takes years.

…this shortage has been around and acute for the past decade.

The same tech hiring shortage we have now is the same one we had at the turn of the century. Microsoft had such hiring problems by 2005, Bill Gates was actively lobbying Congress to ease hiring restrictions overseas since the terrorist attacks of 2001 had made it much harder.

Additionally, it’s a perception problem for new students. In 1999 they were told tech was a path to riches. Then the dot bomb happened, and the media wrote about out of work tech workers with no options, so students fled. Although the opposite now, you still get the same types of scare tactic articles published.

Any software dev who reads even part of that article, or its ilk, will recognize the problems. Learning a new language isn’t what employers need. If you’ve ever done any interviewing or hiring for another company, you’re all to aware of the problems with tech job postings. The job will list 15 technologies when you only need 1. It’ll claim that you must know all 15 as an expert when no one on the planet actually does. It’ll say that you must have all of this or won’t be considered. Sometimes you’re fielded by HR and if you’re honest, you won’t make it through even if you’re the exact candidate they need.

So playing the hiring game is one problem. It has nothing to do with software skills and is rarely taught (well) in schools/colleges. This includes self-marketing, personal branding, and learning how to teach yourself.

The second problem is focusing on languages vs. fundamentals. If you know procedural, OOP, Design Patterns, Frameworks, an IDE, source control, error handling, logging, debugging, formatting, commenting, documentation writing, unit testing, software processes (waterfall, scrum, peer programming, etc), and how to search for help on Google for your problems… it doesn’t matter what language, technology stack, or OS you know. Those same core skills can be applied to any language on any platform. Employers who know this will hire for those skills even if you don’t know the particular language/stack.

GETTING to be noticed by those employers is what you see happen with a lot of unemployed software developers critiqued in those tech journalist articles.

Knowing a programming language doesn’t imply you have core fundamentals. Additionally, you can still remain employed at a company, or get hired to a new one, when you don’t have them.

I’ve worked with companies that have spent $80,000 over 3 months for what they perceived as 10 competent outsourced developers. They delivered nothing excluding emails stating they were working hard. At the end, more money was sent to this outsourced firm to hire more developers… the opposite of what I thought would happen.

I’ve worked with companies who had developers breaking the build every day. The accountability & reprimanding was a company wide email pleading with them to fix the build since with 200+ software devs & QA’s, it brought a lot of them to a stand still for half the day or more over 3 time zones in 3 countries. This continued for 2 years, and only got worse. I never saw any firing or anyone laid off in my 4 months over 2 years there.

I’ve worked with a company where a developer rewrote their core part of a larger application 5 times. Each time, it still didn’t work. They still kept their job.

The stories are countless. The press articles give a false impression of a larger whole that isn’t there. Even a modicum of ability to write code and have it compile will ensure a job. Like writing the first book, the key is to play the game to get the job. That’s the low hanging fruit to learn, not a new language through a college course.

I’m a huge proponent to never stop learning. Even learning 1 new language a year is a wonderful way to improve your skills even in your existing preferred language. A college course can work as well if that is your desired way to learn vs. self taught.

Do not think, however, if you fail to learn the latest new tech your job is necessarily in jeopardy. Depending on the company, I’ve seen teams, not just individuals, who provide no value, are hostile to work with, and yet keep their employment. They continue to produce no revenue for the company years later. Learning politics in that case is more valuable than learning Ruby or Scala. Others aren’t actually specialists, but someone who “codes what they tell me to”. They in effect become Jacks of All Trades in that they’ve touched a lot of technology types for that particular company.

What these developers, who proclaim “evolve or die” statements, are really afraid of, and thus projecting onto the world, is mediocrity. They do not want to be bored, under paid, or unchallenged in their jobs. They don’t want to “have a hard time” finding work or a job. They want to have fun, be paid well, and be challenged all the while being courted with lots of job opportunities. They want to feel that their technology choice is in fact relevant, and ensures they are achieving those goals.

I can tell you with confidence there are a lot of Unknown Coders out there with as much job security as the next coder. This doesn’t even touch upon how hiring a college kid right out of school for $100,000k, who actually costs the company money vs. providing revenue, actually helps the company because it ensures the competition doesn’t get a potential, even if that potential cannot be easily recognized.

3. Using OOP, Design Patterns, Frameworks, and TDD with the Right IDE Will Solve All Your Problems

Learning, applying, experience, working with mentors, and having stakeholders who care & are apt leaders makes software development easier. Having competent designers who get what you do and are actively involved along with helpful QA and good Product Managers also help. As Dave Wolfe said, It Takes A Village.

Just because you know how to use Object Oriented Programming in your particular language, or even many, doesn’t make all the other problems go away. You still have to think how to solve real world problems via code. You still have to think, AFTER you’ve written the code, how on how to make it more DRY. You still have to interpret other’s “perception” of what they consider to be OOP vs. your own. You still have the overhead OOP has in creating more code and have to in turn manage this. In short, you have to think more. Good software allows the user not to think. Code that’s clever is usually code smell.

Design Patterns are still concepts, even if you understand them, and can effectively communicate to team members using those terms to help understanding. Every developer tends to implement them slightly differently. You need to interpret how to apply common design pattern solutions to real world problems. You need to interpret how another developer has implemented a design pattern, and what their interpretation of the value is. In short, you have to think more.

Frameworks are an interpretation by an individual or team on how to solve common software development problems. Using learned conventions, configurations, and forced (re)definitions on existing concepts, you and/or your team are theoretically capable of solving common problems, working together easily on the same code base, and having that code be more easily modified by your team or a different future team.

A framework is usually an amalgamation of OOP and Design patterns with a particular belief on how things should be defined, implemented, and thought about. You need to sometimes change your thinking, adopt that mind set, and teach that to those under you through analogies that are congruent with existing literature on traditional software OOP and Design Patterns. In turn this needs to be related to your current technology stack. In short, you have to think more.

Using TDD, or even just unit tests, or integration unit tests, helps in a lot of places. For building API’s, it forces you to actually be a consumer of the API you are building, and thus results in a better API. It also helps with backwards compatibility. Reading the tests helps document how to utilize the code. For loosely typed languages, it helps reduce the amount of time hunting down null pointers.

You now have to write more code to test existing code. You’ll find you have to manage a separate code base. You have to maintain the tests. Even if you don’t test first, you still have to ensure your code is easily testable. This requires re-refactoring. Usually more challenging, however, is to encourage your team members to not only write their own unit tests, or help you maintain yours, or at least make their code easier to test so you can write them if they are not test proponents. All this assumes your GUI and path of development doesn’t take drastic changes early on negating large portions of your design & code base. In short, you have to think more.

A comfortable developer is a productive developer. A good chair, a quiet (or loud) environment, and a helpful IDE. Doesn’t matter what it is (VIM, Eclipse, Visual Studio), as long as the developer likes it, it helps them code faster, and helps them find errors & debug easier, and thus more quickly. Although learning new IDE’s can make you think more, and take a lot of time investment, whether testing yourself or reading about others’ adventures on blogs, the hope is they actually make you think less… which can help a lot with the above points where you’re required to think more.

Combine this with years of experience, academic and real world learning, and application in a breadth of technology stacks, you should be at the top of your game, never failing. Sadly, this isn’t the case. Simply learning everything there is to know, whether in core fundamentals, or for a specific technology, is in no way a guarantee for success.

The first problem is other developers. Even after you learn everything, getting consensus in programming is actually called “compromise”. Every developer has their own interpretations of implementation details, OOP, Design Patterns, Framework best practices, favorite IDE setups, etc. Some are religiously devote in these beliefs. In driving, no matter how good you are, you need to drive defensive (not professional racing). In programming, same thing; you need to adapt to the developers you’re working with.

Secondly, and more importantly, there are a lot of things that can go wrong, regardless of how smart and/or adept you, or your team, are. This includes users not knowing what they want, stakeholders simply not caring, technical debt created by others, or the company running of out money or simply cancelling the project. Sometimes you’re hired to ensure the project internally or by a separate firm tanks so your firm can take over development. That’s correct: You can utilize your knowledge & experience on how to make software succeed to ensure another software development project fails. Other times you’re just not high enough in the food chain to affect positive change, thus, you keep the Destiny flying for as long as possible.

The good news is as you learn, it does get better. A lot better. In fact, you’ll find that the majority of your time is spent not in software, but trying to fend off those types of problems. Just like how science continually answers questions that just leads to more questions, so too does learning software development lead you to realize there are bigger problems that can set you up to fail that have nothing to do with software development.

Anyone who says by learning TDD or some language will solve all your problems are selling something, or are the types of people who think that awesome, working software that was never shipped is still considered successful. Keep learning, it’ll pay off.

4. You Can Code Something Right the First Time

The best way to code software is to release early and often.

This means you code it as quickly as possible to get a working build in front of real users. You take their feedback, filter their responses into a more accurate flight path, and move forward.

There are a few problems with this. In my experience, most people do not do user testing, even in an informal context. While it’s a horrible shame for companies, it can be dangerous for software developers. There is a reason why Joel Spolsky and others recommend software developers answer support requests from customers. While having incentive to fix the problem is one thing, it teaches relevance.

Software developers, especially inexperienced ones, have strange perceptions of what’s relevant to do at a given point and time. This is completely justified in that they are required to create their own tasking for building software which is complex, has a plethora of details to keep track of, and future ramifications that they need to watch out for because they’ll be the ones to suffer them, and no one else will.

One example, a start up I worked with spent months on building a core product. I continually pushed for, and failed, at getting them to get real users feedback. 8 months in we finally did and we had usability problems. We knew about them, but it was a lot harder then to make drastic design changes. We forged ahead anyway. A year later with the 1st customer, they only actually needed 10% of the interface in a specialized form to run their business. We canned the other 90% and pivoted to use a completely different interface for the CMS to support it. Torching 11 months worth of code, and letting go of a pivotal, valuable team member was completely lame on a variety of levels.

Another example, I had one developer spending an inordinate amount of time optimizing the underlying architecture of a cover flow like component. Being in charge, and knowing how both versions of the component worked, I told him to move onto other tasks as it worked fine. We vetted a build with the customer that day, and they preferred the sortable list vs. the cover flow. I should note that the previous day, the customer liked the cover flow, and felt it worked/performed just fine. The developer in question heard this, and seemed visibility happy to hear this. I can only surmise in their pyramid of needs, their need for approval drove them to hone on this particular component to ensure it performed optimially to maximize the client’s approval of their work.

Bottom line, the client didn’t need it once we provided a better design. Going with this same pyramid of needs theory, the developer started to modify the list control to be faster. While I didn’t agree with the amount of time spent, at least his work was now relevant.

Again, when giving the software to the user, you can validate what you are spending your time on is actually valid. Same with answering support calls; you as a developer have an incentive to fix the problem, both for the user’s sake, and your own.

If you don’t do any user testing, then you have to focus on “getting it to work”. This is why, even without user testing, iterative software development is good in that it forces developers to get compiling code, sooner. They can’t spend 3 days in a cave refactoring some super, awesome architecture because it has to compile and be shown tomorrow.

Another example is DRY. Although some developers think they can predict DRY right out of the gate (like putting methods in utility classes), other times the most valid way of making something DRY is through re-factoring. You won’t see the duplication until it’s created. This happens more in larger projects with multiple developers on disparate and/or non-communicative teams. It’s your job to recognize this after the fact and recommend a solution to reduce/remove the duplication.

Big classes are another. Packages, frameworks, and IDE’s with good search & refactoring capabilities are extremely helpful in managing large code bases. Inexperienced developers think they need to organize now else they’ll be left with an unmanageable mess later on in the project. Not so. You’ll know when it’s getting too big. At that point, you can refactor it out into multiple methods, classes, etc. Obviously you’ll already know how much forethought you can put into it. You’ll reach a point, however, where you don’t know and you’re guessing. Unless you have a valid reason, it’s best to start coding for the now. If you can’t refactor, you’ll learn. Refactoring is the one skill gained through experience which allows you, and your team, to be successful in iterative development.

Plan for what you know, not what you don’t. Being good at refactoring will save you if you get cornered. Remember, 80% of a Scrum Sprint is spent refactoring. No software is ever 100% “right” when you build it. I can tell you, though, if you work hard, you’ll reach a point in your career where you’ll love your code, your architecture, your tooling, and your approach. Your only problems at that point will be preventing politics from sabotaging your courting of users.

5. There is a Clearly Defined Career Path in Programming

Once you become an architect level, you have 3 options: Continue on, become a manager, or start your own company.

I bring this up because no one told me this lie. In fact, no one told me anything. I was raised by good (and bad) role models from the WW2 and Baby Boomer generation. To them, you worked hard, and climbed the corporate ladder for success.

However, some cultural changes happened since their generation. Globalization, outsourcing, and easy to make companies with readily available investment. Software started actually impacting consumers lives, not just businesses. Oh yeah, and the Internet. Once Microsoft became the most profitable company, the Information Age started.

You no longer had pensions at companies. You didn’t work there for life. You didn’t “deserve” certain things because you had seniority. People became a lot more expendable. Replaceable. BA’s and MBA’s no longer guaranteed a job.

I didn’t at the time know any of this and fell in love with software. Fast forward to 2006, and I became… stuck. There wasn’t any clear path on where to go. My father and step-father weren’t any help because they couldn’t comprehend my career path, let alone what was “next” since it’s so vastly different from their generation. The best I could do was research what others do.

What I’ve found is what I’ve wrote. Either you stay hungry and keep learning new things as a developer or branch out into consulting.

Others will turn in their developer hat and go into management, whether as a perceived increase in pay, value, or just because that’s where they think they’ll make more of a positive impact (like the things that affect lie #3). Perhaps they’ve lost the hunger and need something new.

The third is they start their own company. While being technically savvy is good, and being able to target a market you already know in B2B, or even consumer is also good, it’s easier nowadays with readily access to investment capital even if you are a developer.

The other option is just to continue your service work, whether that’s freelance to choose your projects, make more money, or even creating your own consulting or software development shop.

I’ve been with companies that had “career paths” for software devs, but they didn’t make any sense to me. Either they were merely title changes that had very little if anything to do with software, had a bit more authority that didn’t really help with actual development, or lead directly to management positions.

On a positive note, I will say doing architecture for large teams, consulting, freelance, and running or working for startups offers a tremendous opportunity to learn new, relevant skills.

If you’re looking for the old guard style of career path, software from what I’ve seen doesn’t have it. They do have defined paths in government and larger organizations, but the incentives to “rising in the ranks” there are either pay raise, or authority levels, and you don’t code anymore.

Conclusions

Remember, software that makes money is the most important thing. If paying attention to users helps, great but never forget the first.

You don’t have to learn the latest tech craze to stay relevant and employed. You should learn, however, to make it easier if you want career flexibility. Make it fun. It SHOULD be fun. Create sample projects that are creating something relevant. You don’t have to finish, they’re just to learn.

Learning software fundamentals and mastering them will not lead to some software utopia. Individuals are smart, but people are stupid. You’re coding for, and amongst, people. Continue to master software, and then you can focus on the larger problems with much prejudice.

Given how users never know what they want nor can they effectively communicate it (nor clients), and businesses’ needs constantly change, software development is 80% refactoring, 20% calculated risks. Move forward, relying confidently upon your skills. If you need to change direction, refactor.

Knowing that a career in programming results in a life long career in programming, management, entrepreneurship, or running your own software shop, be aware of that early and work towards it vs. suddenly learning about it like I did.