How not to degenerate into only a programmer who stitches together APIs? [closed]

Question

This one I heard when I was recently interviewing a person and asked him why he was looking for a change within an year of joining his previous company. Particularly a company which is known to be in the business of processing high volume transactions, 100s of 1000s of orders flowing through the system every minute etc., etc. (you know what sells, so lets cut it)

What the candidate told me was interesting -- he had joined originally hoping to be able to get into the lower layers of the system, understanding the secret sauce that binds a high volume reliable system etc. What he ended up doing was using a lot of tools - open source and commercial, and was in the business of just glueing it all together, which never gave him any understanding of the real deal. There were tight work deadlines too, so he couldn't really get into the hang of at least the open source stuff either.

I had to agree here. But tell me then, how would you prevent yourself from degenerating into an API stitching kind of a programmer in this specific situation? Are there any signs in the job interview process itself that signal you of this degeneration?

Answer 1

I tend to view using APIs and Frameworks as the Engineering side of building software, as opposed to the computer science side. I take the analogy of the difference between pure theoretical or research science and applying that science into an engineering discipline (different physics into Mechanical, Civil or Electrical Engineering, or Chemistry into Chemical engineering).

Given that analogy, you have a choice: stagnate in your career, just doing what is enough to get by, or get a better understanding of how the science really applies to your discipline, get an appreciation for it, and it will assuredly improve your skill-set regardless if you lean more toward the engineering or pure-science aspect.

Check out this matrix on competencies. If you lean toward the 2^n or n^2 side, you certainly can get good at being a middle of the road developer, and can build software. If you start to head toward the log(n) side, you'll start to see more quickly how good some frameworks are, or even better, start writing your own that makes up for those that fall short.

Answer 2

In many organizations this boils down to their appetite for the build side of build vs buy and how effectively they integrate the things they choose to buy.

A few organizations are heavily on the build side, but most have a fair bit of buy involved. The difference in the latter is how thoroughly and completely they integrate what they choose to buy.

The warning signs for an organization that ends up turning their devs into system integration ops are varied, but a shop with a lot of vendor consulting, no Sr devs that are low-level guys, a large process for architecture decisions, lots of non-technical management within IT or a heavy reliance on paid research like Gartner can all be warning signs that an organization is likely to follow this path.

If you are in an organization that follows these patterns there is little you can do other than try to keep current in your chosen technology outside of work, but discussing soe of these issues with some of the devs during the interview can give you a rough feel if you are walking into a place you feel may be a career dead end.

Answer 3

Even though I have edited this answer to take into account the OPs edits. I still find myself puzzled at the choice of the word degeneration. Bringing together the various aspects of different (and sometimes incompatible) APIs forms a large part of what software developers do. If on the other hand your question is to ask how to avoid getting yourself shoe-horned into a role that you feel is limiting your options to find other work, then perhaps either the parameters you have defined are too narrow, or the view of your role is itself also too narrow. I myself have worked on projects where I was responsible for specific specialist tasks without ever needing to work beyond those "limits", and I have never felt that these jobs were limiting in any way, as I could use them as examples in order to up-sell my skills to the next employer, with appropriate anecdotes about the lessons learned, and the skills earned.

Having myself interviewed many people over the years, I don't see signs that people degenerate into certain aspects of a role. I do see that people sometimes specialize, and that sometimes the specialization is presented as a limitation. This to me is a warning sign that the candidate is not very open minded, and likely doesn't really understand the development process as a whole, or hasn't the capacity to push beyond the roles that the candidate feels safe and comfortable in.

I would find any employer who saw the sort of work that I have done as a degeneration would themselves be likely to have a very narrow view of the capabilities of a good software developer. Software development is more than just being able to code for new GUIs or APIs, and a good software developer knows that there really aren't many opportunities to work on new projects, and that it is rare that you can walk into a new job and get to work on the exciting stuff, because you are generally being hired because there are a bunch of tasks that the established staff don't have the time to complete. Regardless, you will often find that "stiching APIs" together requires the implementation of new API layers to provide greater flexibility and compatibility between the existing layers being brought together. The real questions that should be asked of developers, is do they know how to manage and prioritize their tasks, or how to choose an appropriate methodology for testing and implementation, and whether they understand which tools/technologies to apply in order to achieve outcomes which deliver value to the customer. Essentially asking them if they know HOW to write software, and also how to handle tasks that may not necessarily be as glamorous as they might have hoped.

So to answer what I believe your question really should be about, I don't see that there is anything to fear from finding yourself being directed into a particular aspect of software development, but that if you feel it isn't the appropriate career path for you, you have the option of either discussing options with your boss, or leaving for a different role. If you do leave, then you need to avoid glossing over the work you didn't like, and find a way to draw useful experiences from the work you did.

Answer 4

Degenerate is a loaded term that implies that using API's somehow make you less of a programmer. The truth is, in software you can't escape using some form of interfaces to access the other layers of the system. Interfaces are everywhere, from the instruction set of whatever processor you're working on to the collection of high-level scripts provided by some tool. Good programmers can be effective at any level -- there's nothing inherently wrong with working at any given level.

It's hard to know exactly what your interviewee's situation was. Perhaps he or she was promised one thing and then got stuck doing another with little chance for advancement or change. The politics of advancement vary from one workplace to another, but generally a good strategy for getting to do what you want is to do a great job at whatever you're currently doing.

Your "why are you leaving?" question in the interview wasn't unreasonable, especially in light of the interviewee's short track record, but it seems like one where the answer doesn't tell you much. You don't have any way to know what the real situation was. A more interesting question might be "what have you done in the short time that you've been at your current job?"

Answer 5

Problem is that he didn't have enough patience.

Nobody will let you work on a framework or a platform of a large enterprise system right away.

You'll have to do the following:

• Show the urge to learn
• Make yourself familiar with business by working with a finished system
• Make the right friends and make it clear that eventually you wish to work on a platform, rather than "sticking APIs"
• Gain people's trust

All this doesn't come after a year, especially for a large enterprise system. Yes, it's great the the employee wants to do big boy's job, but there are always plenty others who have already spent years and are more qualified.