Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Someone has already mentioned side projects, my other suggestion is to look at parts of your app where you can break out of the CRUD cycle.

Could you use threading to speed up bulk processing of documents?

Can you use some new package or gem to improve your day to day development flow? (for example, i just found a rails gem that helps speed up start up time for rails tasks, totally using that at work)

How about your Version control, are you using the latest techniques or type of software?

What about learning more about dev ops, how to manage the server and do little things here and there without bothering the server guy?

What about search, are you writing contorted sql queries to hit the databases for your search, or are you using elasticsearch, solr, sphinx or lucene which are better suited for those things?

Is your logging app writing to file logs, or (worse your RDBMS database) or could you use mongodb to speed that up?

Are you analyzing data you collect in an insightful way or is it time to read up on some analytics tutorials, to come up with smarter ways to inspect your data?

how fast is your software? Could it be faster? How can you make it faster?

etc etc etc

In the end it comes down to your curiosity to learn and try new things. That will help you keep abreast of new ideas and help you spot opportunities to apply them sensibly. It should get you from where you are until the point where you feel that opportunities like these are exhausted, at which point, its time to move on.

Never let yourself stop growing as a developer.



There's (almost) nothing worse than stumbling across a project written by a bored developer and then having to support it. Instead of a perl script and some SQL, it will use some smattering of the techs that you mention above. Often not for any real reason, but just because their job isn't demanding enough so they make it as interesting as possible. But it's better for everyone if you do this on your side projects - when you leave your CRUD job someone else is going to have to maintain the wobbling stack of technologies that you used to pad out your resume.


Using things where they don't need to be used is always wrong, but that's almost always just the consequence of a bad developer writing stuff. Not a bored one.

Great portion of developers aren't "bored", they are bad, so they do everything as they go, without optimizing, without planning, etc. When they try using different things outside of their limited knowledge base, they screw up even harder. Creating the unnecessary complexity you talk about.

I find refactoring/optimization to be a necessity and even tho my boss probably won't ever know I optimized X, I know I did it, and I will keep doing it. It's how you grow as a developer, specially in CRUD companies that do not care.

And keep in mind, most developers don't want to get out of the CRUD. And they are very happy with a good paying CRUD job.


I completely agree with this. If you write otherwise simple systems with the latest and greatest technologies, you will often be force to maintain them yourself. The original question was about career growth -- I've seen good developers get stuck in positions that they should have outgrown because they chose technologies that only they could maintain.

Keep your pulse on new technologies, and write your own to expand your expertise. But don't use the wrong tool for the job out of boredom.


Well, I had the opposite experience: as the developer wasn't curious, I had to maintain a codebase with custom (incredibly inefficient) SQL queries instead of a search engine, custom code for which gems exist, pages were never optimised so they became slower and slower etc. in the end a complete rewrite was needed.

As @trustfundbaby says, you can apply new techs sensibly and that's what you should do, without the extremes.

And guess what? You could actually learn something from someone else!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: