Five Lies They Tell You in Software

The following are 5 things I wish someone had told me back in January of 2000.

  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.

28 Replies to “Five Lies They Tell You in Software”

  1. Great article Jesse, alot of great points.

    I especially like the” release early and often” mantra as its constantly a pitfall for me and im sure other programmers too. We too often want to build something perfect first time.

    We dont want to show the world some half-baked idea, the worry is that the idea wont be received as well it could be or that someone else will swoop in and do it better. Its a difficult feeling to surmount.

    Do you have any advice for overcoming that?

    Mike

    1. For consumer based products, yes, I do have advice. People seem to ignore the fact that ideas are a dime a dozen, even if they are good whereas execution is priceless. There are a significant amount of people with good ideas, that is what is so great about the human race. The downside, however, is many cannot execute those ideas, even with a team.

      In large business, yes, there is a worry about showing an idea in it’s infancy for fear of competitors. The example is the iPhone. It was released when both the phone was done, the relationships with Operators were there and signed, manufacturing channels were cemented, and future roadmaps were already laid out. Apple did this because they knew, even if given a year head start, competitors would copy. They don’t need to win, they just need market share. Case in point is Android; the phone blows compared to an iPhone, but it does a few things the iPhone does not:

      1. provides a cheaper alternative to the iPhone
      2. gives every other manufacturer beyond Apple an OS to use that doesn’t suck (like Symbian)

      Google, even with as much money and brain power as they have, still haven’t released iPhone like quality. Only Apple can (could?) do that. Additionally, they were not market leaders/first to market. All that combined ensures Apple retains a lead for a long time, but more importantly makes it extremely painful for the competition to catch up.

      …that’s not us, though, releasing small B2B or B2C products to small/mid-size businesses and consumers. Additionally, as a developer, while hiring help is hard in this market, there is nothing more rewarding than users using your product and immediately asking for things. You would think you’d just want them happy, but no. Remember back to the first time you used Flash, or Director, or Photoshop, or Facebook, Google+, Twitter, etc. You knew it was good in retrospect because you wanted to add things to it… AND You continued to use it.

      If it user asks for things AND uses it, you’re golden. It’s when they make suggestions and never use it is when you need to go back to the drawing board.

      You never have that opportunity if you’re in a cave thinking you can read the user’s mind. In programmers defense:

      1. We can’t exactly plan releases to a T; sometimes it may in fact take 4 extra hours to wrap something up.
      2. Sometimes we just enjoy programming in and of itself.

      #2 is why a lot of products never get released. Not because the product isn’t valid, nor that it isn’t on track, but rather, the programmer would rather code vs. execute and get done.

      There are 50 billion ways to say it and I don’t know what is the best way, but bottom line: There is no greater satisfaction when you know your purpose in life. As a programmer, when you know what a user wants based on real user feedback that’s been filtered, that is the greatest time to be a programmer writing code.

      1. Wow cheers for such a long reply Jesse.

        Thankyou for clearing up those points for me. Me personally as a programmer I enjoy making tools that others use. I enjoy the feeling of making something easy to use that will either bring enjoyment or enhance the productivity of the user.

        As I think about it I think the enjoyment I get most from it is related to you point. Its the iterative loop of user-request, feature implementation that drives me to improve the product. Perhaps it best then to release something with a small nugget of value first then build upon it as users request more.

        Interesting..

  2. Very much liked this, answered a few questions for me.
    Thank you.

    “Individuals are smart, but people are stupid. You’re coding for, and amongst, people.”

    1. Thanks! It’s a play on words from the movie Men In Black:

      Edwards: Why the big secret? People are smart. They can handle it.

      Kay: A person is smart. People are dumb, panicky dangerous animals and you know it. Fifteen hundred years ago everybody knew the Earth was the center of the universe. Five hundred years ago, everybody knew the Earth was flat, and fifteen minutes ago, you knew that humans were alone on this planet. Imagine what you’ll know tomorrow.

  3. A little bleak.

    On some levels I agree about the money concept, but at the same time I am going to continue thinking about the users first. I am in this to make their lives a fraction better/easier. That is what I enjoy doing and why I like building enterprise class software to begin with. I fully understand the motivation of the legions of MBAs with their PMI certs hung in a nice little row on the wall, but I will still fight the good fight for my users. I consider that part of my job.

    One of my favorite books on this topic is Apprenticeship Patterns. It is about how to build a solid rewarding career in software development. The “Breakable Toy” chapter is excellent that talks about building something for yourself. Something that you can play with and manipulate without worrying about how it affects others.

    1. I agree. It’s just dangerous when you see legions of blog posts online claiming that’s the most important thing, and a high level executive ignores you when you’re trying to affect positive change by having a conversation with them. If you cannot communicate on their level, recognize what’s important to them, you’ll come across as some dogmatic underling and the user won’t be saved from the stupid shit they’re making you do. As a team lead, it’s all about running defense.

      Thanks (yet again) for the book reco, added to Amazon Wishlist. Maybe someday her majesty will start buying me those books (yes… yes… the How to Read a Book one first…)

  4. Thanks for the article Jessie, your insights into a career path within software development are very interesting and, as you say, we’re covering new ground so traditional advice is obsolete.

  5. Nice post and well said. For the most part I’m 100% on board with you. This is the Kool Aid that a generation (or more) of developers has been fed. Some see through the lies and become better for it, most don’t, and in my experience, have the joy of development turn into the dread of development.

  6. Nice post, I would say many of your lies apply to the enterprise software domain but do not normally apply to the gaming industry, mainly the user being the most important as an indie developer I can tell you the user is definetly most important I have sales stats to prove it. That being said your posts have always been a great learning experience for me. Thanks Jessie.

    1. Go read Gamasutra.com or any of the other 2008/2009 drama around over worked game developers.

      1. User vs. Money
      Forced, unpaid over time to ensure they ship on time.

      2. Evolve
      Still written in C++/C/Assembly.

      4. 99 Problems
      Games sabotaged not by bad coding, but bad design direction, mis-management, and lack of effective leadership. La Noire = 6+ years to make, single game published, made millions, studio went out of business. Black Isle, produced some of the best RPG games of all time from Baldur’s Gate, Icewind Dale, Fallout. Drama with Interplay over control, entire staff laid off (although most already left when they saw the signs). Nothing to do with coding, all with stupid business politics. I could go on and on.

      5. Career Path in Gaming
      Same career path. Only difference is gaming companies have a Design Agency model, and care more about creative direction than engineering prowess. In effect, even what you do matters less than what a designer does. Not only do you not have a career path beyond management or opening your own studio, but your discipline isn’t even considered the most important.

      So… yes, applies 100% to gaming. Now, see point #1 about not being about the money. I agree user centered games can make money, especially in the virtual goods strategy (see Zynga). However, for the majority of people, it does not pay their mortgage. Indie game dev is about satisfying a personal need, sticking it to the man, or creating games the developer(s) wants to create vs. the corps they could work for. None of those 3 things are first and foremost about money, and are not ways to make a living in software.

      Until Indie Game Development pays my mortgage, the above applies. Yes, I’d love to re-write this blog entry to exlude it. Yes, I’m trying every night with Corona SDK.

  7. I must say the beginning of this post is poorly worded. I thought you were telling me lies. I read the first line and bullets as the table of contents, maybe some rewording could help:

    “The following are 5 things I wish someone had told me back in January of 2000.

    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”

    You touched on a subject that I have been concerned about for some time:

    “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.”

    My lofty dream of wanting to create at least one piece of software that someone can’t live without is a dream that still doesn’t feel well suited for Flash, yet I’ve pigeon holed myself into this platform (having spent over 7 years becoming an expert and doing very little else). It is nice to hear someone say that I might be ok in the long run, but since I am no designer, I fell very limited in my job choices (also because I’d rather not do agency work).

    My personal view of it is that the flash market is split like this:
    80% agency/ad
    13% games
    5% mobile
    2% products

    does that match other people’s views?

    1. Thanks for the feedback.

      Technology choice doesn’t matter. I’ve seen successful products written in VB.net (not C#), C++ for the web (yes, before Chrome’s NativeClient), JavaScript, Python, Appcelerator’s Titanium… technology doesn’t matter.

      What matters is your passion, hard work, and if your software does in fact jive with what your target users really need. At that point it’s about responding to those users, marketing, and finding the right business model. Some startups do the reverse; business model first, marketing, and finding & responding to users. Both approaches can work.

      For Flash, I’d agree with you. Most people who hate agency work and do Flash end up going Flex to do software. There are always people who dislike when I say that and are quick to attempt to destroy the stereotype, citing companies who write pure ActionScript 3, use standard software tools & practices, etc. but I think you’re percentages are mostly right… cept mobile, I’ve gotten jack. ‘Course, I still need to modify my marketing in a few weeks and start advertising again.

      Products I think is higher since a lot of products out there utilize Flash. Hulu.com, Amazon.com, etc. both have video products in the consumer market. Flash isn’t the sole tech, it’s a part of a greater whole. If you use that as your metric, then Flash is insanely higher.

      Keep trying to reach your dream, mate. It’ll happen.

  8. One of the best articles I’ve read in years (in terms of useful information content).

    Thanks Jesse.

  9. I still believe in “evolve or die”. You’re young. Let’s have this conversation again in 10 years and still see if you’re awash in Flex work. I’ve met plenty of old Director pros who evolved. And a few who died, and then reluctantly forced themselves to evolve.

    I agree that some get too dramatic about it. It’s not like you need to learn the hot new language of the year every year or wind up in the unemployment line. But yeah, you gotta grow. You’re not using Flex 1.5 exclusively are you? Even if you were, you could still find some company that would hire you. But knowing the latest version gives you a lot more options.

    Even before I was into tech, I had a programmer friend who had a great job with a company for like 10 years. Then the company went under. He had gotten comfy and hadn’t learned anything else and found himself unemployable.The nearest company that needed what he knew was 3 states away.

    I think your COBOL reference is misleading. Yeah, the old infrastructure is there and will stick around for a long time, but times are different now. Things move much faster. Technologies come and go in years, if not months. Especially in front end web technologies. The only reason the Flash platform has stuck around as long as it has is because Flash has evolved. And those using it have evolved with it.

    1. I hear you Keith. However, for every story I hear of someone who has a tough time finding a job, I see 5 people at a company who know a non-bleeding edge technology who can produce just enough to convince management by having an SVN check-in every 2 days, they’re adding value. The # of stories compared with the # of how-the-heck-are-you-still-employed programmers I see just doesn’t add up.

      I used evolve as “using bleeding edge technology”. For example, if you haven’t even given Node.js or Coffee Script a look see yet, I’d considered that not evolving in the context of this article. Even so, you can still find tons of Ruby on Rails jobs, a what, 5 year old tech now? I’m sure it’s older, but 2006/2007 is when I remember the hype for it going crazy.

      I started with Director. Then Flash. Then Flex. Now? Who the heck knows, whatever ends up being fun.

      That’s me, though. I always try to find the most recent, fun stuff to use. I just think it’s wrong when people say you SHOULD do that to remain employed based on how many people who treat programming like a day job, and learn only when absolutely necessary like your example, they’d prefer to stay in the same state. I agree you should do that if you wish to have an easy time finding employment, picking and choosing what projects you wish to work on.

      My point is, there is an 80% out there who just get by. They don’t play with new technologies at night, build games, read blogs, attend conferences, write blog posts, yadda yadda. That should hopefully be a sober, and positive, reminder that even a little self-investment done has large rewards and should make you feel good about yourself.

  10. You’ve given us great food for thought. Thank you. In fact, I’m off to post this in the hallway at school.

    To hear employers tell it, there is another myth, too: The myth that you can ‘get by’ with basic communications skills. In post secondary IT programmes we see students who choose IT because they are strong in math and perhaps not so strong in communications and/or people skills. They are often encouraged by well meaning caregivers and truly believe these skills don’t matter much in this industry. Popular culture certainly reinforces this cliche. (Sadly the most extreme cases still end up working in boxstores.)

    But employers involved in curriculum advisory panels (which have a huge impact on curricula) beg for students who have more of what they consider to be fundamental workplace skills such as greater general knowledge, a grasp on basic business concepts, and the ability to see ideas from various perspectives. Communications skills, both interpersonal and verbal, are always stressed.

    Their frustration, it seems, is with IT staff who do not see their role in the larger context, have no vision of how their skills may be effectively applied to improve not just both product quality but also the quality of materials produced by their workplace teams. Forgive the cliche, but they seem to want fewer introverted geeks with computer tans and bad shoes. (ducks, then chuckles) Since I am already in the dangerous waters of stereotypes, I should mention that we see the female graduates hired in greater percentages than the males, based on the perception that they are more well rounded and can communicate well. (Or could it be because they put “plays well with others” on their resumes?)

    So loud is this industry cry that whole new degree programmes have been developed to meet it. It’s interesting to note that in an era of decreased IT enrollment worldwide, these programmes are very attractive to students and have engaged segments of the student population who shudder at the antisocial geek stereotype.

    So, my friends, from your point of view, is this Myth or Mrs? Comments s’il vous plait?

  11. Really solid article – and I agree with almost everything that you discuss. I’ve been in the industry for 20 years and after my first 10 years selected path number 3 (starting my own shop). However, after being both a developer and product manager, the issues with running a company are just as complex as writing great code. After 10 years of running a shop, I still have a lot to learn (mostly on the business side). Many days, I wish I could just settle back in my chair, enter the zone, and write code for 8 hours (the good old days)
    Great article!

  12. Hi Jessee,

    Learning OOP and Design Patterns doesn’t guarantee you’ll be able to program worth squat nor does keeping up with all the new trends guarantee employment. Further, if I did everything my clients wanted, they’d go broke (or in one case to jail).

    However, learning OOP and Design Patterns in my case broke a lot of bad habits and helped me understand loose coupling and gave me a far broader and more useful handle on developing applications. Doing the same thing again and again in a changing environment is not only boring, but I do believe self-defeating in both the short and long run. In the short run, you’ll miss opportunities that open up with new technologies. I lucked out and had the first book out on the Commodore 64, and it sold 350,000 copies–not because I’m the Ernest Hemingway of computer books, but rather because I took the time to learn something new. I did the same thing with HyperText, and bought an airplane with my first royalty check.

    In working out things for new technology, I would suggest judicious selection as you suggest. However, just because you like hammers, you shouldn’t try to build a house with one–ignoring saws, screwdrivers, drills and everything else you need.

    Kindest regards,
    Bill

Comments are closed.