How to avoid being an API programmer only? [duplicate]

Question

Possible Duplicate:
How not to degenerate into only a programmer who stitches together APIs?

I have almost six years of experience in java. I have developed many projects which used frameworks like Struts, Spring, Hibernate, JQuery , DWR, Ajax etc.

I have used these technologies in almost all the projects I have worked on. Projects were very simple mostly with crud based apps.

My everyday tasks involves creating few screens, writing queries, testing etc.

After all these years I feel like I have turned into an API programmer who just uses these above mentioned frameworks which is not giving me any satisfaction of being a programmer.

Is this normal or is it just me who is feeling like this?

Answer 1

First, there is nothing wrong with being an excellent API programmer. There are plenty of non-trivial challenges that can be addressed entirely within the confines of framework APIs - after all, that is the reason why these frameworks were created in the first place.

If the level of challenge at your current position does not give you enough satisfaction, try moving up the bar that you set for yourself. It is often up to you, at least to a significant degree, to decide what you make of a project assigned to you. See if you can

• Complete your assignment significantly faster, or
• Complete your assignment with significantly less code, or
• Complete your assignment to a significantly higher standard of quality, or
• Significantly decrease the amount of debugging you need to complete your assignment

Doing this consistently should eventually bring bigger and more complex assignments your way, increasing the challenge level. Usually, the new challenge would come from the business aspect of the system that you are building, not from the coding of it.

Answer 2

Yes, this is absolutely normal and there is no reason to feel bad about it. Do you also feel bad for not coding a custom OS and device firmware for every single project?

Every programmer is only an API programmer

It's what you do with the APIs that defines the value and complexity of your work.

Whatever you do, do not start reinventing wheels in work projects just to increase your personal satisfaction. Do so in your free time, or when there is a concrete reason why for this particular project's requirements, none of the existing wheels are adequate.

Answer 3

I agree with you as I found myself in a similar situation 1-2 years ago: I had something like 4-5 years of work experience, and 90% of it was using heavy frameworks and implementing the same CRUD-like (sometimes web) apps. Here's my 2c on this:

1. I see that some people say that there's nothing wrong with only working like that. I disagree. It's one thing to use Spring batch and write a bit of business logic, and it's entirely different to do your own multi-threading batching engine, tailored to the type of treatment you'll be using it for. It's more complex, the category of challenges and issues is completly different. The same goes for dropping from Hibernate-only data-access application to using a low level driver and making your own code to deal with the data. Just the optimization issues alone change completely, and those are only half of the major differences in paradigm. So yeah, I think you miss out A LOT by only being an API programmer, at least that's how I used to feel.

2. Luckily now I have work projects which avoid greatly the use of "famous" frameworks like Spring, Hibernate, even Servlets in favor of custom made, from scratch, code. This is because the projects I had at work were not very common, and these generic frameworks are really made with a certain type of project(s) in mind, but don't work well for others. Also there was the issue of performance: putting aside all the other pitfalls of making your code from scratch vs using a library/framework (speed of development, less bugs, more tested code etc), from a strictly performance-wise point of view it's almost always better to avoid a library/framework and do your custom code specifically tailored for the problem at hand.

3. Never forget that one of the greatest advantages of open-source development is that you have all you need free to access whereever & whenever. If your curious how to implement this and that without using a framework, try doing it at home, by yourself. You don't have to make a project similar in size and goal to those you have at work, that would be unwieldy, you'd waste a lot of time, but try prototyping certain things just to see how that goes. For example I've tried coding by hand different types of game loops (which later on I used to make simple games), I've tried implementing various algorithms (like AStar), I played around with MongoDB driver to see how it can handle CRUD operations without extra help from other frameworks, etc.

Answer 4

If you're not constantly finding ways to push yourself outside of your comfort zone, then yes, there's a good chance that you'll feel like that. I know a lot of people who have lost (or never had) their passion for learning and are simply happy going through their daily motions. Nothing wrong with it, but it's far from me. Sounds like that's not what you enjoy either.

Do something different. Work in a different department. Find another job with a company that's not doing the same thing your company's doing, or at least has more diversity in areas that you're unfamiliar with.

Of course, if you're bound to your job for the time being because it's a good paycheck and you have real life responsibilities (i.e. you're not a fresh grad still living in your parent's basement), then take on some OS projects that put you outside of your comfort zone and force you to learn something new. Who knows? If you find something that you're passionate about, you might gain yourself enough experience to go into the field professionally (if it's something that you currently don't have enough experience doing).

Answer 5

This can be normal, particularly when you are tight on resources or people setting direction are unimaginative (not a criticism, they just might be non-technical). The big question is where do you want to go?

If you want to be a better developer, learn about the business problems you are trying to solve. Read trade magazines or blogs. Attend conferences. Do a training course. Talk to the users. The more you know about how the product is used, the more you can contribute to its direction and the more valuable an employee you will to be. You can then propose things that are a bit more adventurous than CRUD.

Expand your horizons, too. Start a side project at home to push what you know. Explore a different language or library. Find an open source project on github, write some documentation or tests for it and ask they authors if they can be added to the project.

Talk to other developers within your organization. Have a weekly lunch together where you talk about problems, debate solutions or just muse about the IT industry in general.

Alternatively, if there is someone in your organization or industry you admire, talk to them and ask them for advice. If you are respectful and appreciative, you'll be amazed how helpful others are. You could also find someone else that needs mentoring and offer to help.

Many of the tools you mention are open source. Maybe pull down their source code, learn them and submit updates. Write some training materials or short tutorials and host them on a blog.

If you want to move into management, start volunteering for situations where you can take more responsibility. Look at things outside development, too, such as being a fire warden, joining the social club or working on the 401K committee. Start learning about budgeting, basic accounting and project management.

Depending on your relationship with your manager and his/her technical expertise, it may be worth talking about it with him or her. They might be distracted with other issues and not aware of how you feel. Indeed, if you want a promotion, do not wait for your boss suggest it to you. Driving it yourself is one of the things management looks for.

Answer 6

About 15 years ago when I started programming for a job, less APIs were available, just because there was not as much out-of-the-box libraries available.

Nowadays with modern IDEs and extensive libraries either built in the library or development tool or 3th party libraries, APIs are more and more important.

However, there are still a lot of challenges, even with just using APIs: - architectural decisions, i.e. what about usability, maintenance, non functional requirements. - design desicisions, i.e. usage of design patterns, objects, classes etc. Also modelling has become more and more important - implementation: this part has been made easier over the years, and thus less time consuming. - testing, allthough testing was always needed (or should be needed), testing is more and more important to the increased complexity of software in general.

How to avoid: - try to get up int he direction of making more design decisions or architectural decisions. Also since UI / GUI is more and more important, focus into that direction, especially if you have creative skills.