Interviewing Software Developers based on Changing Technical Debt

How to Interview Software Developers based on Changing Technical Debt


Interviewing a Software Developer isn’t easy. Interviewing a Software Developer is a high stakes gamble where the choices made are often ill-informed and the result of a choice has enormous consequences, both good and bad. The entire interviewing process has been flawed since the very first “Programmer” job was posted, many moons ago. If you have the time and patience to read this long-winded article, I believe I can help you make a more informed decision using my own experiences interviewing, hiring, working as a consultant and full-time employee, and my own opinion about the most honest and robust hiring strategy I believe in.

When it comes to hiring, there’s a lot at stake for the interviewer and candidate alike, so let’s begin by discussing the interview from the vantage point of the manager.

Understanding the hiring manager’s aspirations

Managers often hope their new candidate is going to be the “one” who charts a new course for their product, their company, and ultimately, paves the way toward golden opportunities for everyone on the team. Managers have visions of hiring someone so special, they can work normal hours, get a better bonus, and lengthen their lifespan through the type of stress reduction they were advised to undertake by their Cardiologist.

After a candidate is found, interviews happen. An offer is made. Anxiety fills stomachs. Email clients see their ‘receive all’ button pressed over and over. Papers are signed. Videos about “why groping is inappropriate” are watched. Then, months after an understanding is reached about what the candidate would bring to the organization, both parties are often disappointed by the differences in expectations for the position and the reality of the position.

The interview is where all of the false expectations are born. Having worked as a full-time employee, consultant and founder of two start-ups, I’ve had my fair share of interviews on both sides of the table. I have hired freelancers, contractors, consultants, and full-time employees. I have gotten lucky, and have been seriously blown away by some of the people who worked for me, whom I never would have imagined would be capable of carrying the baton across the finish line; and yet, succeeded beyond my wildest expectations. Other times, I’ve kicked myself for a costly hiring decision that drained so much time and energy, I would have been better off doing the work myself.

I used to suggest we hire a candidate based on their intimate knowledge of subject matter. When I hired, I often prided myself on my ability to ignore personality, as if my tolerance of the more eccentric candidates provided me a bigger talent pool from which to choose; a tolernace I believed provided me an edge over our competitors. Everyone who hires usually tells himself or herself that they have some edge over other interviewers. They tell themselves they provide a much more thorough interview than their peers. They tell themselves they can judge a candidate’s fitness better than anyone else. They tell themselves their cowboy shirt they picked up at the thrift store looks nice. Remember this about interviews: Interviews happen off-the-cuff because interviewers have no systematic process or methodology to successfully measure a candidate’s real value.


The Scrum Master’s Guide to a Better Scrum


I’m old mature enough to have worked for companies that used a Waterfall methodology to deliver their software. There was always something nice about having time to figure out problems on your own with a longer time frame, and I liked reviewing a pile of documents (honestly).  Back in the day, I would walk across the street to a restaurant and review the documents that were related to my task at hand. Then, I’d begin coding, knowing we had a once-a-month show-and-tell of our progress, just to keep our contracts. New requirements? Another lunch-and-learn.

Most companies have moved to an Agile approach to Software development, and after operating two start-ups with daily changing requirements, it’s clear to me why this approach works.

However after working for several different companies, I’ve realized there is a plethora of companies that consider themselves agile, but they’re not Agile. Sometimes, they claim to be somewhere in the middle of Agile and Waterfall, which is one way of saying, “We’re still trying to work it out.”

These companies often have a Scrum which isn’t a real Scrum. For simplicity’s sake, we’ll call this the “Artificial Scrum”.

For all of those companies that are still trying to make Agile work, I’m going to help, by introducing this blog post, which we’ll call, “The Scrum Master’s Guide to a Better Scrum”, to help understand how to turn an Artificial Scrum into an Authentic Scrum.


A Maven seed project for GWT, Google App Engine and JDO

GWT and AppEngine Convention, without IDE Configuration

A Maven seed project for GWT, Google App Engine and JDO


This project offers a conventional seed project for a full-stack application that is pre-configured and ready-to-go. The goal is to offer a simple, working example of a CRUD application, using an entity relationship framework, enterprise-level validation, which sits atop a cloud-based, schemaless, high-replication datastore that has zero dependency on an IDE. How is this done? The entire dependency management and build lifecycle configuration is done solely through Maven.

This project currently supports the following:

  • Google Web Toolkit 2.7.0
  • Google App Engine 1.9.18 through a schemaless high-replication datastore (HRD)
  • DataNucleus JDO 3.0
  • JUnit 4.12
  • Google Chrome. Due to the limitations for symbol-map support in IE and Firefox, you need to test with Google Chrome to see error log messages logged by the UI.


This project is licensed under Apache License 2.0

Project location


A few years ago, I was working for a company who let developers use their preferred IDE, using a BYOD approach to the authoring environment. I thought that was very cool, and I also believe it’s an approach likely to gain favor as more companies move to a Docker containers for development.

Some developers kept their own lifecycle mappings for Eclipse, some developers worked purely from the command line, and others benefitted from how IntelliJ introspected parent POMs to understand dependencies. Some developers kept their own m2e configurations.

At the time, I didn’t have any experience with Maven. Lots of developers lack Maven experience, and there’s a steep learning curve with Maven, especially if you need to create an environment-specific configuration, such as working in Eclipse with m2e.

I prefer IntelliJ it for development, but my preferences shouldn’t dictate the team’s preferences. Lots of people prefer Eclipse or Netbeans. For my most recent application, I had a hard time finding a starting point for my GWT/GAE/JDO project that didn’t include IDE specific configuration, and I had a harder time finding documentation and examples which didn’t omit the intricacies between the different SDKs and frameworks.

So, when my company decided to move from Eclipse to IntelliJ, we came across a few issues with our migration. First, it became difficult to share a project between Eclipse and IntelliJ. We had been using Maven for dependency management, but not lifecycle management.


Validators with Formatters in a Stateful Form

I’ve released a project on GitHub called Form & Function. I build this project and then used for a large Eligibility Application for a client, where it proved pretty useful. The problem domain I was dealing with dealt with how to develop a large, forms based application where user-feedback needs to be rock-solid and the feedback needs to happen constantly, to ensure as many fields get completed in a single setting as possible.  

In a nutshell, what does it do?
Form & Function
reminds a user that their time-investment matters to you and your organization by giving the best possible experience when filling out a form.

In brief technical jargon, what does it do?
Form & Function creates the relationship between a validator, a formatter, and a restrictor for the most popular form types, and then notifies the developer and user about a form’s validity.

Who does it help?

  1. For developers, it simplifies building complex forms.
  2. For users, it helps them complete long forms.
  3. For project managers, it’s a milestone met.
  4. For user experience designers, it’s a starting place for a conversation.

Where can I find Form & Function?
The code base is hosted on Feel free to download the latest version of Form & Function from the Subversion trunk. Over the next few months, the project will be in a “Bleeding-Edge” release, and should not be considered backwards compatible from day-to-day.

What problems can Form & Function solve with my Flex Project?

Problem 1: The standard Flex Validators are too generic
Let’s start from the top and talk about the Adobe Flex validators. The types of validators Flex currently offers are:

  • CreditCardValidator
  • CurrencyValidator
  • DateValidator
  • EmailValidator
  • NumberValidator
  • PhoneNumberValidator
  • RegExpValidator
  • SocialSecurityValidator
  • StringValidator
  • Validator
  • ZipCodeValidator

Adobe gives you all the hooks you need to build your own validators using the Validator class and the RegExpValidator class (and both are used liberally with Form & Function).

The more specific validators, such as the CreditCardValidator, won’t validate credit-card security codes, only credit-card numbers). While a Merchant may not require the user enter a security code, the ability to validate against a security-code that’s tied into the card-type, should have been there all along, along with a CreditCardFormatter for user legibility.

Form & Function has validators that either improve upon, or plain-old, don’t exist in the latest Flex SDK.

How to Get Hired as an Adobe Flex Developer or Adobe Flex Contractor

In the movie Rustlers’ Rhapsody, Tom Berenger’s character tells the locals in the town he’s come to, that all saloon towns are the same: each town, he tells them, has a town-drunk, each town has a town-prostitute, and each saloon town has a black-hat cowboy (and the black-hat cowboy can’t win in a gunfight because he’s a bad guy). How does the nomadic white-hat cowboy know all this? Because he goes from town-to-town and he’s seen the same scenario play out over and over again.

The State of Flex Developers

As a Nomadic Software developer who has worked on the Flash Platform for the past ten years, let me tell you something: most software companies are pretty-much the same, from town to town. At each company, you’ll see some of the following types of Flex Developers:

  • There’s one Flex developer who does 80% of the work, and then spends the rest of his time getting caught up on the latest technology (which requires the rest of his conscious time).
  • There are a few developers who were hot when AS1 was the rage and they’re almost ready to move to AS2. But in the meantime..
  • There are the Flex developers who somehow got moved from Java Development to working on the client-side (and they didn’t consider this change to be promotion).
  • There are the Flex developers eager to learn something new, but they have no idea how to go about it.

In short, I see people who are burnt-out, not-interested, not-interested and unhappy, or interested and frustrated.

Things Have Gone Wrong

There are always a lot of jobs opening up in Development, and I rarely see developers much older than I am (I’m only 33). Neither one is a good sign for career prospects, but what does that say about the Software that IS out there? How experienced are the people who are building the software that impacts our lives when they all seem to be so young, and worse, young and (see categories above)? Well, I’m glad you’ve asked!

To all of the developers out there who wake up and think, “I will never learn how to do this. I will never learn all the stuff I need to learn to become really good at Flex Development and have a life”, put down your whiskey-glass and pay attention.

The Software Industry is a cut-throat business

Most saloon towns (and yes, I am going to stick with the Wild-West metaphors for the rest of this post) only have enough room for a few cowboys, and there’s another one riding-in with a fancier gun and a faster horse.

If you lose your job working in one of the smaller towns, you’re either going to have to relocate, market yourself so aggressively you can work remotely from home, or look for a new line of work. In a big city with a focus on technology (like Raleigh-Durham or New York City), the competition for software jobs can be fierce. Software is one of the highest paying fields that doesn’t require an advanced college degree, and that is a major draw for a lot of people who have the basics down, and are willing to go to any length to have the salary of a medical doctor in less time than it takes to finish medical school.

Software is a new business and it changes fast.
The processes for building a physical structure, like a town-hall, have been around for 1000s of years. The processes for building software have been around for 40 years, and web-programming only took-off around 1996. For the past few years, people have been coming out with proposals for processes that are then tried, proven and refined, or tried, proven false, and tossed out. We’re STILL figuring out what works and what doesn’t work, and software development is still in its infancy. You should expect things to change rapidly over the next few decades. Roll with the changes. You need to know how technology changes. You need to learn what to follow and what not to follow. You need to know how to stay ahead of the curve. You need to do it in a way that is efficient so you can have a job and have a life. If you don’t keep up, you’re going to walk into the street one day at high-noon for a show-down and find out that the other cowboy standing at the end of the road has a bullet-proof vest beneath that duster.

You Won’t Learn Much At Work

Companies aren’t going to pay to train you. It’s not in their best-interest to ‘hope’ their financial investment in your education is going to pay dividends in profit for their next fiscal quarter. Unless you possess some special product knowledge, it’s cheaper to replace you with someone who already knows how to solve a complex coding problem, because that person is going to come up with elegant solutions that won’t just save time coding, but will make it easier for Mary and John in Quality Assurance to test other areas of the product, and it means Susan and Phil in Marketing can start selling the product sooner and it means Jenny in User Experience is going to have plenty of time to fine-tune the interface. And besides, even if your company DID train you, what’s going to prevent you from leaving once your skills have grown? Now that you’re more marketable with a higher earning potential, it’s time to open on and begin anew!

Software Developers Have a LifeCycle, too
Software Developers are only valuable if the skill they’re bringing to the table is in demand. The Flex SDKs evolve every few months. A new Flex IDE comes out every 2-3 years. And the tools and approaches begin a Sea Change about once each year. With such an enormous learning curve, it doesn’t take much to fall behind.

How soon can you become irrelevant?

  • You can become irrelevant in 2 years at a small company.
  • You can become irrelevant in 4 years at a Fortune 500 company.

How Can You Mitigate the Dreaded Fall-Behind?

Propose a Radical Change (or just do it)
I’ve been to a lot of meetings with people that have lots of industry experience. I’ve sat around tables with managers who have MBAs, developers who have advanced degrees in Computer Science, and the kind of documentation that makes you believe the enterprise-application we’re about to launch has been carefully thought-out. Then, after a few weeks (or a couple months if I’m new to a company, their people, culture and processes), it becomes clear that the people are well-intentioned, but they are missing major pieces in their development process (and they all know it, too).

I may walk into a company and say, “You have no automated build process. You spend 2 days each week doing the same thing. You have developers with different environments, so they spend a solid day each week trying to figure out why an issue in QA can’t be replicated on Bart’s workstation, but it can be replicated on Wyatt’s workstation with ease.”

Then, I ask, “Why not add an Automated Build Process?”

The answer is always the same: “We don’t have enough time.”

The answer is going to be the same whether we’re talking about refactoring a code-base to design patterns, adding a version-control system, implementing a framework, or adding an automated build process.

By default, your boss is going to tell you “No.”

The Unspoken Truth about Your New Enterprise Approach

Enterprise practices will probably absolutely save you time on your next big project (and all projects grow in complexity and become ‘big’, anyways). Enterprise practices help to ensure projects get completed. Enterprise practices keep morale high and prevent resources people from quitting in the middle of the morning Scrum resigning at the end of the project. Enterprise practices reduce tension and friction between team-members. Enterprise practices will help to ensure you go home by 8pm, 7pm,6pm, 5pm (going home at a reasonable hour ensures mothers and fathers see their kids and the enterprise practices ensure loved ones see their significant others. Going home at a reasonable hour means you’ll probably workout and eat a healthy dinner and watch a movie).

It’s NOT cool to talk about these ‘desires’ at the next Business Requirements meeting. IT IS COOL to talk about how amazing the project is going to be when it’s done and how valuable you’ll all be!

Steps If you’re In the beginning of a project:

  1. Find a process that is popular and would apply to your project.
  2. Implement 1 new enterprise practice into your project (and act like it was totally expected if anyone asks). From this,
    • You will benefit
    • Your company will benefit
    • Your team will benefit
  3. Immerse yourself in the new practice over the next two weeks, and then tinker with it for an hour or two a day.

Steps If You’re In the Middle of a Project:

  1. Find a process that is popular and would apply to your project.
  2. Memorize the buzzwords.
  3. Understand intimately how the process applies to your project.
  4. Understand intimately why the process was never implemented or suggested. You may end up attacking someone’s competency or your own, so be prepared to vigorously defend your newly-held beliefs.
  5. Propose a new approach. Tell your boss that your company MUST implement a _______.
  6. Prepare for the rebuttal of, “We don’t have enough time to implement _______”. Explain why implementing the process will save you time, money, and a loss in morale.”
  7. Repeat the proposal as a Mantra.
    1. If the company elects not to use your approach, show them as the project moves forward that you could have saved time (and money) by using your idea with specific examples in the moment. I often use, “I guess we could have been out having beers instead of doing this again [bonus points for a dead-pan delivery].” Don’t let your proposal be forgotten.

Choose the right company and learn on the job
The processes a small company adopts are centered around a development approach that produces a more robust product in less time, with fewer developers, even if that means rapidly learning something new. You could be working on Flex one day, and Silverlight the next. You could be working on JavaFX and then back on Flex. The small companies are not bound to the same constraints as a huge company. Small companies have flexibility and choice. You can walk into a small company and propose a development approach you’re interested in learning, and your boss may let you run with it. And by “propose”, I’m talking about going out to Starbucks with your boss and proposing the adoption of LiveCycle or agreeing to migrate to a new SDK while he’s adding extra ice to his Venti Iced-Coffee.

At a small company, you’re going to need to learn new platforms on the job, which often means you have to request to be moved to projects that offer you the opportunity to learn new things. Show initiative and be very honest if you feel like you’re not being put on a project that will make you more marketable (if you think there are other options).

A Fortune 500 company is slow-moving, and it’s usually one major platform (or 2) behind in each release cycle. The Fortune 500 company has a major perk if you’re a Self-Starter: if the code you’re working on has reached a milestone earlier than expected, you’ll have time to download and experiment with the latest languages, methodologies, and application servers on the company dime while you wait for the others to catch-up (and remember, your goal is to look busy so you don’t make your boss look like he’s not managing. He knows what you’re doing. Just don’t bring your start-up to the office).

In Old-West Speak: There’s a big difference between Tombstone, Arizona and Tucson, Arizona. Choose the town that gives you the best opportunity to learn new things.

Learn how to be resourceful
In 2003, the project I was working on was winding down. I had finished the programming and I was bored out of my mind. I was still an entry-level programmer and I wasn’t learning anything new. So I joined UltraShock, a Flash forum. I would go through the posts with questions I didn’t know the answer to, and I would search out the answer, write the code, test the code, and the post the solution.

I received lots of emails and posts thanking me for helping someone solve a problem, but I was really helping to advance my own skill-set. I also taught myself something very valuable: I am fully capable of finding a solution to ANY programming problem. I learned the true skill-sets of my peers (what they were good at solving even if they didn’t enjoy solving the problem), how to search through live-docs, and I learned the power of networks (someone always seemed to know someone who had special knowledge of a topic).

In Old-West Speak: Prove to yourself that you can setup camp between any two saloon-towns and survive based on your resourcefulness. Can’t find the instructions for setting up your tent? Can’t read the instructions for setting up your tent? You need to prove to yourself that you can find someone in the next town who can teach you.

Work with someone smarter than you
In 2004, I took a job in Jacksonville, Florida. After having worked a contract in San Diego and having enjoyed the weird, transient lifestyle that is Reno, Nevada, I wasn’t exactly keen on moving to Jacksonville. My girlfriend at the time was interested in moving back to her hometown, and my boss was pretty honest that the product we launched wasn’t selling and I was a drain on payroll.

I was assigned to work in R&D as a Flex Developer. My team-lead was exceptionally bright, and he taught me Object-Oriented Programming, Object Relational Mapping, and Frameworks. He moved me away from the world of procedural programming that I had found to be comfortably familiar, and helped me to transition into real software development. He helped me over a hurdle that was difficult to learn on my own by mentoring me.

Just remember, if you’re an entry-level developer, that’s okay. I’ve always been amazed how perceptive managers are when it comes to understanding the competency of their employees (even when they pretend to be incompetent). If you don’t know how something works, open up and be honest about your confusion. Whatever you do, don’t pretend to know something. In Software, you get a gauge on someone’s competency pretty quickly.

In Old-West Speak: Find the first School-house you can, and listen carefully to the school-teacher. Sit closer if it helps, and don’t worry about what the other kids say about you being the teacher’s pet (you probably won’t be working with them in a few years anyhow).

Learn from Blogs, but Filter out the Noise
Most blog aggregators feed off the blogs of thousands of developers. Most of the bloggers don’t contribute much to your learning. Follow the handful of developers who are going to give you a glimpse of their experiences with the latest in Flex Development. Don’t waste time reading the blogs of people who aren’t going to offer valuable insight. You can learn a lot from a small group of people, like Jesse Warden, Brian Riley, and Ryan Knight.

If you’re not eagerly looking forward to the next post a blogger writes, you shouldn’t be reading the blog. If you’re thinking about buying the blogger a Christmas present because he or she has taught you something that has enriched your professional career, you’re on the right blog.

In Old-West Speak: A lot is said down at the Saloon. Strangers like to talk and share stories. Ignore almost everything you hear in that saloon, unless it comes from the mayor or the sheriff.

Build a Small-Scale, Enterprise-Application
One of the beautiful and terrifying parts about technology is how massive milestones have reduced job-security. When I was starting out as a programmer in 2000, the DBAs were the highest paid positions with the most job security. By the time Hibernate evolved and became common-place, DBAs were no longer the foundation of all projects. With Adobe LiveCycle Dataservices and the Fiber Modeling Plug-in, most of the work that was done on the client by a Flex Developer has become the ‘domain’ of the Java Developer. Much of the work that the DBA used to do will now be done starting in the Model that drives the DB creation. Much of the work the Java developer used to do is now done based on services the Model generates. It’s awe-inspiring to see how much quality code Fiber can generate, but Flex Developers will soon need to know more about Model-Driven Development (Including Hibernate and Java) if they’re going to stay relevant.

It’s important to build a product you’re passionate about. It doesn’t need to be enormous, and it can be a product that does very little, but it needs to utilize an entire enterprise-stack. By building and evolving this project, you’re going to learn languages, platforms and application servers you never knew about, and you’re also going to learn how those things work together.

  • Learn a tool that makes life easier. Try Cairngorm 3 Validation
  • Learn a mainstream framework. Try Parsley
  • Improve the quality of your code using a Code Quality tool. Try FlexPMD
  • Learn a unit-testing framework. Try FlexUnit 4
  • Make all of the above work with an automated build-process. Try Ant
  • Learn some Java. The support for Java and Flex integration is excellent, the language and the OOP concepts are similar to Actionscript, and the tools for Enterprise development are robust. Try a Java Tutorial.

In Old-West Speak: Build your own Saloon Town that can stand the test of time, even if each building is the size of an outhouse.

Look Into the Future of Trends (and position yourself accordingly)


In 2004, Caringorm was the standard framework for Flex development. It was also the only choice. Last year, most of the contracts I was working on used PureMVC, and two of the client courtships required PureMVC experience. By the end of 2009, most of the contracts I was courting were using or moving towards Mate or Parsley. Now, RobotLegs is gaining some momentum and Cairngorm libs are being coupled with Parsley as the framework of choice.

You can’t learn every framework. Worse, when you’re out there interviewing for that next great Flex job, you may find that the team interviewing you is dead-set on finding someone who knows the framework they’re using. Don’t feel like you’re incompetent because you’re not familiar with every Flex framework.

A framework is an Architectural Design Pattern, and all Architectural Design Patterns look to solve the same problem: An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.

Rather than jump on the framework-of-the-week bandwagon, look at where the time, energy and money is being spent by examining the Trunk of Apache’s Flex SDK Open-Source Project. Don’t worry about learning every framework, but always be familiar with the direction of large teams who shape and mold the future of technologies.

Don’t worry about the next Flash-Killer
You’re going to see a danger to your livelihood quite often. You’ll see competing skills required in “Wanted:Flex-Developer” job postings. You’ll think you’re falling behind or you’ll think the world hates Flash. Focus on what you enjoy and if you ever need to make a switch, you should see the writing on the wall about 2-4 years ahead of time, and when you do know, rest-assured there will always be jobs to tide you over until you learn something new.

Automate quality on Friday. AKA: Friday is for Refactoring
Projects grow in their complexity very quickly and the best way to know you’re moving a project forward is to know you’re contributing to the growth of the code-base, not duplicating it or obfuscating the code.

You’re going to meet developers who are going to tell you that you’d be just as good as them, if only you worked harder to “just get it done.” You’re going to see developers who show you how to do something in ColdFusion, JavaScript, and PHP that can be done in just 10 lines of code[!]. Developers are going to tell you that with Actionscript and Java, you’re going to be writing 100 lines of code for every 10 they would write in another language. Remember that a Robust product is never measured in the sheer number of lines of code. The ability to output a variable in fewer lines of code doesn’t reflect the integrity of the code when there are new conditions applied.

I’ve had clients who wanted to measure my productivity by the number of lines of code I’d written. Yet, I’ve helped Fortune 30 companies to move a stalled product from stagnation into production by refactoring a project to a fraction of the size it once was.

You should obsess over the idea of writing code that is reusable. Tools like FlexPMD and FlexCPD can help to ensure you’re writing quality code. Books like Martin Fowler’s Refactoring: Improving the Design of Existing Code will help you to write better code.

Set-aside every Friday to refactor the code you’ve written all week using the latest tools and proven methodologies. Write less code.


In 2004, ColdFusion with Flash Remoting was still the standard in two companies where I was working. Both companies have since moved to Java with a Flex Client. By 2007, WebServices was the norm with Java. By 2009, most of the companies were using Java with BlazeDS. Next year, I suspect most of the projects are going to be incorporating Adobe’s beautiful LiveCycle Data Services with the Fiber plug-in for Model Driven Development.

Learn RemoteObjects

Don’t worry about learning every single RPC as a Flash or Flex Developer. I’m going to take it one step-further and encourage you to skip-over WebServices altogether. Don’t bother with JSON, XML, or HTTP.

Most of the companies I’ve worked for have used one or all of the above to get their software up and running. Those same companies are working on Legacy platforms. When you work with real entities through BlazeDS/LCDS/AMF/GraniteDS, you have the opportunity to work with real-objects that have a direct correlation to identical (or slightly transformed) objects on the client.

Model-Driven Development with Flash Builder 4 and LCDS represents something more than a simple-code-generator. MDD with Fiber and LCDS gives small companies and enterprise organizations a starting point to eliminate hundreds of tasks developers used to implement manually.

Programming is a Living. Programming is not Living.
Six years ago, I was driving in my truck with a good friend. It was late in the evening and we had just finished unloading some boxes of furniture I had given him as I prepared to move to Atlanta. I brought up work, and my friend asked, “Why is it that whenever software developers get together, we always talk about work? I miss talking about R/C airplanes.”

My friend had a valid point: Software Development requires so much time and energy, that it’s hard to leave work at the office. Some of the problems are so complicated and so multidimensional, it’s hard not to leave the cubicle and ponder the possible solutions. Now, looking back at the past 10 years, I can honestly tell you that I haven’t solved many problems thinking about them after-hours.

Worse, I haven’t really had any conversations evolve after I answered the notorious question of, “So what do you do for a living?”

People have a frame of reference for “Software Developers”. And the second someone hears you’re a “Programmer”, they have visions of you sitting in your mother’s attic for three years without any friends, trying to reassemble the Atari you disassembled, just to prove to yourself you could put it back together again.

If you hang-out with coworkers after work, you’ll tire of your job much more quickly. Social-skills come from regular interaction, and experimentation. These same social skills are important at work, and they’re important to having a real-life. You are not your job, even if you’re at the office more than you are at the house. Each time I have an ad-agency as a client, I’m reminded how charismatic the designers and marketing people tend to be. Each time I have a software consultancy as a client, I’m amazed how introverted developers tend to be, with no inflection, a rapid speech rate, slumped shoulders, and poor eye-contact. Their body-language and speech patterns often reflect their self-confidence.

Don’t let software become your life. If you become a Flex Developer and Stay a Flex Developer, come up with a plan to keep learning, while you explore other interests and find new friends. Get on and find something else to do, but do things to remind yourself that writing solutions to solve complex problems can be a great way to make a living. But it’s not living.