
Ask HN: How do you escape CRUD jobs? - diminium
You know the drill.  When you left college, you wanted to work for the big guys - Intel, Google, Apple, NASA - doing things which can change the world.  You wanted to do stuff like create a compiler or figure out an algorithm.<p>Unfortunately, reality hit back hard and you got stuck at a typical company doing CRUD operations. Make reports here, manage documents here, upgrade calendar software here.  It pays pretty good but it's not the dream you wanted.  Irony then rings and the deeper you move in your career, the more CRUD experience you get and the less "let's design the next generation algorithm" experience you have.  Thus causing those companies to pigeonhole your resume to pass you on for someone else.<p>How do you escape from this trap?
======
edw519
You're asking the wrong question, my friend.

Don't blame the CRUD for all the bullshit that is often associated with it.

(Reminder: CRUD stands for Create Retrieve Update Delete, and is the
underlying philosophy for the database applications that run the world we live
in, the 90% of the iceberg that most hackers never see or even think about.)

I've been doing CRUD for 33 years and it's been an incredible ride. I credit
my CRUD work for putting me in the right hand 5% of that bell curve, ahead of
the rest of my fellow hackers who have built so little of substance.

Sure, I've built apps that move people and things to the right place, and also
have done a lot of "reports here, manage documents here, upgrade calender
software here", but what job doesn't have some crap work go to along with the
gravy? I've never seen any good job without it's share of maintenance,
refactoring, testing, process, and meetings with drones.

I've also build software that generates other software, invented new
frameworks, and devised algorithms that dramatically improved the way we make
and build and move the stuff that's probably in your cubicle right now. I've
taken cool academic theory from my pure mathematical background to build
software that has blown away the posers everywhere around me. And you know
what? You do that just once, and every champion in the enterprise runs to you
with their giant budgets to solve their CRUD problem du jour with your
"genius".

Believe me, you don't have to work at "Intel, Google, Apple, or NASA" to
"change the world". You're just as likely to be a cog in the wheel at those
places as anywhere else.

You can change the world from where ever you're at, and in fact, if you're
working on a CRUD app, I think you're actually in a _better_ position to do
it. You just have to ask a better question.

My suggestion: "How to you escape the shackles and bullshit of your CRUD job
and use all those great resources in your head to turn that job on its side
and change the world from right where you're at?"

Find the answer to that question. It may be easier than you think.

~~~
michaelochurch
I think he's using "CRUD" as a metaphor for "crappy assigned work that hurts
your career". This has nothing to do with "CRUD" so much as the
dissatisfaction that sets in when you realize that the shots, in most of the
world, are still called by morons with no vision.

Actually, I think CRUD itself is a good thing. Why? Because it's a description
of a simple interface. You really get the elegance of a CRUD API in the
corporate world. Normally, you have a bunch of stupid features and
requirements that attached themselves like barnacles.

In truth, building CRUD apps places a person well above the average in the
typical corporate stack. At least you're building new stuff and have a chance
to shine. Unlike on a maintenance job (which is what most people get) you
_will_ get visibility if yo do good work. Most corporate denizens don't even
get that. They're lucky to write 200 lines of new code per month.

 _My suggestion: "How to you escape the shackles and bullshit of your CRUD job
and use all those great resources in your head to turn that job on its side
and change the world from right where you're at?"_

The problem here is that most people need an income, every month, or they
start to have serious financial problems. Knowing where overperformance
leads-- getting attacked by envious/insecure idiots and ending up unemployed--
I wouldn't recommend it unless he has financial security.

~~~
pcl
I've noticed this sentiment on HN a number of times. In my experience at large
companies and small ones, I've never seen overperformance turn into
unemployment. I believe it has happened, but I doubt it is common, and I
certainly don't think it's common enough to base job decisions on.

In my experience, I have seen the opposite a number of times -- people who
overperform have been rewarded with more responsibility and more-interesting
jobs. This includes situations in which people automated away their job
responsibilities.

~~~
michaelochurch
_In my experience at large companies and small ones, I've never seen
overperformance turn into unemployment._

It's more subtle than that. People don't get fired directly for
overperformance, so much as they make enemies who later sabotage them. It's
hard to do anything important and not piss someone off.

I have an overperformance story from Google that's legendary, although I
didn't actually get fired.

Overperformance doesn't inexorably lead to termination, and it's certainly not
immediate. It is, however, more likely to lead to termination than the
opposite. (On the other hand, underperformance is more toxic to your career in
the long term.)

"Performance" is a middle-class myth for AFCs (Average Frustrated Chumps). You
get fired if you fail politically. Being at either extreme, performance-wise,
increases the likelihood that this happens.

~~~
hga
I suspect some of it has to do with your personality and how much your over-
performance engenders envy.

Looking at my work history, it cost me 3-4 jobs at companies that subsequently
failed. The best example is one where the new and essential product needed to
avoid an m*n database transaction explosion, where m is the number of clients.
My warnings about this---and it was very easy to explain and the math is
rather simple after all---kept me off that project and sidelined to a dead
end. The project ... went even worse than expected, was never reliable after
the 2nd client logged in (the project manager had never even done a multiple
client system before), until a new crew was hired to rewrite it, but it was a
little late by then....

When Mr. Church say "You get fired if you fail politically." he's spot on.
That was obviously a factor these jobs and cost me another one or two. All of
these were small companies, except for Lucent during it's year of free fall
from 106,000 employees to a targeted 35,000 or so; they ended up getting
bought by Alcetal.

Here's a constructive comment (I hope): one thing you have to watch out for is
managers who are failed programmers. Even worse is if they had no input into
your hiring.

------
qdot76367
It's a long game, but building what you're interested in, even if it's the
boring parts of what you're interested in, can get you noticed. Due to writing
drivers and tools for people to use different hardware, I've now worked
in/with:

\- Robotics (via working on open source educational robotics stuff)

\- Virtual Worlds (via making hardware to interact with them)

\- Health Devices (via reverse engineering health devices)

\- Neuroscience (via reverse engineering eegs)

\- Haptics (via reverse engineering haptics controllers. Noticing a trend
here?)

\- Digital/Interactive Art (via writing Max/Puredata/OpenFrameworks/Processing
plugins for aforementioned projects)

\- Teledildonics (via [censored])

(My github is at <http://github.com/qdot>, where you can witness the ADHD
firsthand)

And the list grows every time I start working with a new library or device.
Most of my dayjobs tagentially relate to something I've worked on in my spare
time, though I try to keep from taking a job that'd completely subsume any one
interest, as that tends to be a permanent mood killer (I'm looking at you,
popular virtual world company that crushed my VW dreams).

So yeah, just find what you're interested in, do something in it, try to be
part of a community around it, and let things work naturally.

Then comes the hard part: Tying all of this back together via /you/. You can
make neat stuff all day long but if you can't tie it together with your own
personality, then you're just a person who aimlessly cranks out neat stuff,
which is something that will worry employers. Presenting a complete and
coherent package of all the stuff you're interested in and why you're
interested in it, with proof that you can do (more importantly: finish) it and
show how that can benefit others is really the key. But damn, is it ever hard
to get there.

PS stay the hell out of teledildonics. That is MY TURF.

~~~
omegant
Teledildonics... ROFL! XD best branch of telematic robotics ever!

------
meaty
Welcome to software development. You have just discovered exactly what 90% of
it is. applying canned solutions to known problems. Roll up your sleeves and
dig in.

Even our massive financial platform is a glorified CRUD box with a mere three
bits of cool algorithm stuff which have been the same since 1995.

Most of it is pasting bits of crap onto more bits of crap.

Even google apps is pretty much just a big CRUD system.

The art and science is making all these operations scale. Well that's what it
is for me. 50 operations a second - no problems. We hit 10000 queries/second.
Things work differently then which is where you have to turn back to deep
computer science knowledge.

I've developed a deep knowledge of mathematics, statistics and algorithms
trying to keep CRUD systems alive. we write our own cache, store and messaging
layers as well as a logging system that can keep up with the audit
requirements of the above.

At the end of the day, its quite interesting if you don't shrug it off.

Embrace what you have.

Edit: I am also the guy who gets all the traditionally shitty jobs. The hard
things to debug, distributed bugs, timing and locking issues, race conditions,
reliability problems, the 3 day debugging sessions, the Microsoft patch
breakage dance and the 'its 2am and everything just caught fire' jobs. I LIVE
for this. I am literally the last hope every time. I never lose. Being trusted
with this and as the last line of defence is an honour and why I rather like
what I do as well.

It's always challenging if you go looking for challenges.

~~~
liljimmytables
You're right about CRUD and canned solutions. On the other hand, I think that
OP is in fact bemoaning their lack of investment in the product- that "CRUD"
is just the most notable feature of it. So I would agree and disagree with you
at the same time: "embrace what you have" is true for "embrace this approach
to development" because it's good, and you will find joy in the details.
However, "embrace what you have" is false for "I'm doing a job where I have no
love for the things I'm making." The longer you try to embrace it, the more
damage you will do to yourself and to your employer.

------
kalyan02
Build something. Anything. Small or big, doesn't matter. Just build - in your
free time. If you don't have free time, make time. What to build? Pick
something that you wish software/hardware did, but you don't know any that
does.

~~~
trustfundbaby
I cannot upvote this enough. When I was getting started on rails years ago, I
found it hard to make headway just making headway on a project I got dropped
in the middle of.

It wasn't until I decided to migrate a personal project of mine from php to
rails, and had to set it all up on a VPS with Phusion Passenger, all by
myself, that I made that order of magnitude jump in skill level from novice to
intermediate dev. Having that side project has also let me try out so many
different things I could never be able to try out at work without know if it
would work or not.

Those countless hours you spend off the clock screwing around with something
just because you want to is simply invaluable to your progress as a developer,
this is why to this day, I keep an eye out for developers that find time to
hack on side projects.

------
trustfundbaby
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.

~~~
mprovost
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.

~~~
Draiken
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.

------
codewright
Build up a portfolio of the kind of work you want to be doing.

You don't get a job in compilers by complaining. You do it by getting commit
access to gcc.

Hop to it.

Alternately, do a startup in the space you want to be in and let VCs pay for
the privilege of you educating yourself. Either way.

~~~
thedigitalengel
I was very lucky in the sense that I could participate in two Google Summer of
Code programs. With some relevant experience, I'm now in a good position to
get the _exact_ kind of job I want (which also happens to be related to
compilers / VMs).

------
symbion
\- Do non CRUD work outside work \- Once you have enough experience/knowledge,
seek out a non CRUD job.

~~~
ChuckMcM
I think this is really key. You have to realize that your employer may be of
the type which says "Well anyone can do this CRUD stuff so we'll add him to
the pile" and that is probably true, but if you're really capable and
passionate you'll be doing the CRUD and learning new stuff too. Talk to people
at work about the cool stuff, if you manager is someone you can talk to, talk
to them about it. Learn what you can, build things. Find a non-CRUD project
that you could do that would make your manager look good, then explain that to
them and get their buy in. They are doing it to look good but you'll have
solid experience on your resume when you blow town.

The biggest mistake new college grads make in their first job is that the
_only_ thing they can do is what their manager told them to do. Sure you have
to do that stuff too but if you're smart, figure out a way to get that stuff
done _and_ get other fun stuff done. That stuff you get to pick for yourself
so it will be, by definition, not CRUD.

~~~
ritratt
I am stuck with a CRUD (testing) job. Been trying really hard to get out.
Learned python. Created many side projects at work to improve current process
and personally to expand horizon and geow. But whenever I go for an interview
for a development position, they are always like, "We currently need someone
who has hands on experience with <relevant technology> development. So we
cannot take your candidature further." Really demotivating. Feels like I am
gonna be stuck as a tester for life despite having so many ideas and
knowledge!

~~~
jyu
You're probably not applying to the right position, or start using <relevant
technology> for side projects. Not sure where you are, but it seems like there
are more and more openings for web developers.

------
karterk
You need to find an actual problem that stretches what you know and demands
you to dig deeper into areas of computer science that interests you.

Reading theory and books won't get you far as you will realize that the real-
world problems bring a lot of perspective that is not documented well enough
in most books.

So, how do find a challenging problem to solve? Most people will suggest
working on side projects, but some _really_ hard problems (e.g. distributed
computing) requires resources that make it impossible to pursue as side
projects. Also, having people much smarter than you around you helps with the
learning. So, the alternative in this case is to join a start-up or a big co
just so that you get a chance to explore difficult problems.

------
wturner
I don't think your question really has to do with programming. I think it has
to do with the feedback loop of being pigeon holed, age and job history. There
is a Robert Greene book that just came out called "Mastery" which I haven't
read, but I listened to some of the promotional interviews he's done. He talks
about this a lot and part of the book is about breaking out the cycle. I'm in
that state right now with my current "job" predicament.

------
zura
There is one interesting observation from my experience - the less developed
(or even banana) the country is, the more (or exclusive, for banana countries)
demand is for PHP/ASP.NET/J2EE etc Web/CRUD stuff.

On the other hand, in more developed countries, the demand is quite big for
C++/Desktop/3D/Compilers etc "good stuff".

Web + large scale JavaScript stuff also falls in the latter case, although I
don't consider it as "good" ;)

~~~
potatolicious
> _"On the other hand, in more developed countries, the demand is quite big
> for C++/Desktop/3D/Compilers etc "good stuff"."_

I don't think this relationship really holds. It's really more like: in every
non-US country the overwhelming demand is for CRUD stuff. The demand for non-
CRUD software is almost exclusively an American phenomenon.

This is, of course, somewhat of a generalization, but I do believe the trend
holds true.

I grew up in Canada, where the software scene is _very_ heavily CRUD. The main
CS employers in town are such exciting names as SAP, IBM, TD Bank, Royal Bank,
Bank of Montreal, and Scotia Bank. I spy a pattern. The demand for "higher
level" programmers is _tiny_ (there's a Mozilla outpost, and a small
smattering of startups few people even know about).

From talking with friends internationally, it seems like this is the case in
the UK and France also - all highly developed countries.

The only place where I've seen any substantial opportunities for C++, 3D,
compilers, and other non-CRUD code is in the US.

~~~
raverbashing
It's not as clear cut as this

There is a lot of C++ work in 'developing countries' (dependent on the country
as well)

No 3D in France? Have you heard of Catia? There is C++ as well

YMMV, even though I like working with low level programming, the high level,
semi-crud work can be nice and with less BS

------
Lapsa
There are no CRUD jobs and it's not a trap. Actually - it's quite a shame that
so many programmers dream about hacking through hyper-hard algorithms instead
of understanding people around.

------
moocow01
Seek out opportunities in other industries/segments of computing.

The reason a lot of work is CRUD work is because most web applications and
business applications are just data/information management systems targeted
toward a certain use. My unscientific guess would be that 95% of at least
minimally complex web and business applications boil down to being CRUD with a
UI and a lot of marketing spin. This means that if you work in this segment
you are going to be mostly working in CRUD. There are many other segments of
computing where your work will be incredibly different.

Examples:

\- Computer graphics/gaming

\- Embedded systems

\- Networking

Caveat - after working in a new segment you most likely will find that they
have their own 95% core competency skill set (like CRUD is for web/business
apps)

------
methodin
You can almost always extract more from your current employer (if you haven't
been doing so), you just need to demonstrate the passion and will to do
different things. If you do chances are you will get some more opportunities -
if not then it really is a dead end and you should move on. The biggest
mistake you can make at any job is to not learn or take away anything from it.
Sometimes you just have to ask for what you want.

Jobs should be more than a paycheck. You exchange your time/effort for
growing/learning. Both parties are aware of it and should act accordingly. If
one party is not living up to the bargain it's time to find a new partner.

------
SandB0x
Lots of related discussion here: <http://news.ycombinator.com/item?id=2052362>

Your company probably isn't interested in switching to cool language x or
doing that big rewrite that you'd hoped to lead. You'll have to identify the
skills you need for your ideal job and work on them yourself.

A great first step is a to automate repetitive parts of your job using
languages and tools that you want to learn. Don't ask if you can do this, just
do it discreetly at first. It's a good stepping stone between the familiarity
of your job and side projects at home.

------
martininmelb
I've had some CRUD jobs and some non-crud jobs. Interestingly, all the CRUD
jobs came through Agencies and all the non-crud jobs were direct. There may be
something there...

------
joshcrews
I'm speculating here, and may be wrong.

You may have a more "I don't know how I got here, but I kinda feel like
somebody's slave" problem than a CRUD problem. If that's your problem, there's
an eject button that will be a wild and scary ride, but you're likely to come
out more healthy, excited, passionate and feeling alive. Go independent (as in
quit, become a freelancer/consultant).

If you do, your initial contracts probably won't be on the forefront of
changing the world; but I'm speculating that that's not your problem anyway.

After going independent, and learning all of the self-management and business
skills and establishing a reputation you'll also get more project offers than
you can do and you'll be able to choose ones that change the world more, and
the impact of your projects will probably go up overtime. And at that point,
you'll also be hunted by the world-changing organizations that seem so distant
now (if you want to leave consulting and go back full-time)

------
__--__
There is one way to change programming fields that almost feels like cheating
and is a feature unique to startups in Silicon Valley.

Find a company doing the work you want to be doing that's currently in crazy
startup staffing mode. That's how I went from writing CRUD apps to making
facebook games.

I was completely unqualified for video game development, as most of my
experience was with web-based CMS's in PHP, but I could solve fizzbuzz and
they were desperate for programmers.

That last part is key - they wanted to launch 30 games in one year and didn't
have the manpower. They grew from 30 people to 300 in one year, and 300 to 600
the next.

The downside to this is you need to be able to learn new skills and languages
fast in a high stress environment. But, if you do it right, you can learn a
lot in a short amount of time as well.

------
mseebach
So _what_ do you want to do? Practically _nobody's_ full-time job is changing
the world, and for everyone who does manage to put a dent in the universe,
loud opponents will tell you you're doing it all wrong. First step in
"escaping" is having a vision of what escaping looks like. What _really_ makes
you happy? As others have pointed out, escaping may very likely still look a
lot like a CRUD app. Spend some weeks keeping a diary, taking note everyday of
what you did you liked and what you didn't like. Try to figure out the "why"
for each of those. A pattern will likely emerge.

------
josh_fyi
There is tremendous demand for software engineers today. No matter that you
are doing CRUD, employers need you.

They can't see your code that you developed at work, so a Github with some
quality code would be good -- but the key is to remember that there is _some_
employer out there who is better for you, and that that employer needs you as
much as you need them.

Try my webapp, fiveyearitch.com , which we've optimized exactly for employed
software engineers who want to scratch your itch.

I think it's important to leverage your current job, not escape it. You have a
powerful starting position; you just need to hop over to a better job.

------
programminggeek
Start by figuring out how to make it better. As in, automate the boring parts
and fix the parts that suck. Also, start building something cool. Like,
seriously, build something cool. Even if it's just for you.

I've been geeking out about software architecture and engineering lately to
make TDD not suck, so I built Obvious to scratch my own itch. It's the most
fun I've had building software in years. I don't know if anyone else is going
to care, but I've enjoyed it immensely. <http://obvious.retromocha.com/> if
you're curious.

------
andrewtbham
I recommend clearly articulating your programming experience. Reading your job
description I can't tell if you're doing programming or sys amdin/support desk
type stuff. Like "upgrade calendar software." Are you installing upgrades or
writing the upgrades?

Also, what do you mean by crud? I assume...
<http://en.wikipedia.org/wiki/Create,_read,_update_and_delete>

------
orangethirty
Back when I started working on cars (like a million years ago) my dream was to
build hot rod Ford Mustangs. I would devour every magazine or book that was
about doing that (I still have a bin full of them). Why Mustangs? My brother
loved them. He worked and worked and bought himself a pretty beat-up example
(an '82 GT, which was slow as hell). In that car we had countless adventures
that I still cherish to this day. Like that time we drove about 20 miles in
around 5 minutes because the parts sotre was closing and we needed a part for
a Corvette (another story altogether). Or the time the crankshaft fell into
the oil pan, thus leaving him stranded and engine-less (it was pretty funny).

So, I got into cars because i had a dream of modifying Mustangs. My brother
had a friend who was a Racing mechanic that speciliazed in Mustangs. We hung
out at his shop night after night. I kept learning how cars worked (I was
around 13 years old), and how to modify them.

Years passed and I had turned into a walking Mustang library. I could quote
the specs of every Ford Racing Camshaft (still can). I kept working on cars.
Little by little I kept getting experience. But I was not getting any
experience with Mustangs. Shoot!

Tinme passes by and I own a repair shop. Im a full fledged mechanic. Working
on cars was _fun_ , but it didnt make me happy. My dream was Mustangs, not
Toyotas with a bad power steering pump. But I kept going.

After a while, I got the chance to work on Porsches. I quickly learned all
about them and got into the art of modifying them. It was fun, but they were
not Mustangs. Got as far as working with other high end Euro cars such as the
BMW 850 V12 6-speed. Fine car. Sucky build quality.

Went back to fixing regular cars because I had to pay the bills. I still hadnt
modified a mustang per se, but knew how to. I wanted to buy one of my own but
could not afford it. There I was wanting to do something, and not doing it
because I thought I couldnt.

Then my brother passed away. With him, my desire to build Mustangs went away.
Turns out I just wanted to build Mustangs with _him_. You know, make him
proud. At that moment I realized that we have to ask ourselves what do we want
to do and do it. Instead of beating around the bushes, just go straight and do
it. Life is too short to waste time on shit that doesnt make you happy.

Even though I dont know you, I can say the following. If you are tired of
building bullshit applications at work, then quit. Save up some money, quit
and take another job doing whatever it is you want. If you cant find a job
doing just that then start your own company. Funding these days is easier to
get than Malaria.

The problem is not CRUD apps (which I actually like doing), or algorithms. The
problem is that you feel stuck. Un-stuck yourself by making a decision and
sticking to it. It is better to make a bad decision and in the way fix it,
than to wait until conditions are right (which they will never be).

I never got the chance to build that Mustang with my brother. You will never
get another chance to write amazing software either. Carpe Diem, my friend.
Carpe Diem.

------
bozho
You can get some motivating stuff done even without changing the field.
Specializing in something cool and strange is fine, but as someone mentioned -
there will probably be a 95% repetitive task there as well. While staying at
your current industry segment, you can still do interesting stuff: I've
discussed that here <http://techblog.bozho.net/?p=1063>

------
patz
Hi, I'm a QA in a industry company and I'm doing these daily manual testing
just because I was a previous field engineer and knows much more about the
domain than my fellow colleges. I'm so tired of such kind of job since
everyday just get exhausted doing these test. I'm in a great puzzle about what
to do next, and I'm also wondering what can I do if I change my job. Can
anyone give some suggestion? Thank you!

------
bryanh
Smart hackers are in really high demand so this shouldn't be that big of a
problem. Talk to a few companies that do interesting things. Most are hiring.

------
ssylee
I have trouble finding a CRUD job to work in. At least the expectations from
employers are not that high.

------
Executor
Join foundations like Apache, FSF, Linux and Mozilla? Join open jobs like
Valve, Github, 37signals?

Either way... I don't think changing the tech world is the answer. It's our
SOCIETY that needs changing, requiring people to be politically active, self-
educate, protest, etc.

------
wenbert
Find different ways in doing it. When I do not have time, I do it like how I
did it in my previous projects/work. When I have some time, I try do it in a
different way - look at my previous code and then try to improve.

------
shreyash02
Boring jobs exist everywhere even at Intel, Google and NASA.

------
swapnilt
Hmm..Maybe do something like - 1\. Resign 2\. Start/Join a startup

------
vegas
You quit.

------
Aqueous
You have a job. Stop complaining.

------
martinced
Tired of CRUD? What about learning CRA (Create Read Append)?

There are _so_ many places where people did add "time" information to CRUD DBs
because of the 'U' and 'D' that it's not even funny.

Learn a CRA DB and go apply to companies using _today_ technologies that shall
be used in the future mostly everywhere.

Most CRUD DBs I've been working with would have had absolutely zero space
issue had they been using a CRA DB. And this would have solved so many issues.
The only downside of "CRA vs CRUD" is that CRA DBs tend to be bigger (not than
the CRUD one who did poorly re-model time that said)... But with today's
hardware and especially memory growing up so fast and going down in price so
quickly (the two being related but not identical), it's really not a problem
anymore for 99.99% of the companies out there to simply store facts in a "ever
growing, append-only" DB.

Just an example: there are many times where someone up the chain asks for some
information and you either have to ask the DB guys to give you a backup of the
prod DB at "time X" on some DEV/PREPROD environment _or_ you have to go fetch
business information by parsing logs.

These are two major fails. And they're mostly related to the fact that most
CRUD DBs are modeled as "non factual". The 'U' and 'D' are irreversible
operation losing business information and developers time.

So learn about CRA DBs like Datomic (which you can, btw, back with a SQL DB
like PostgreSQL) and then go apply to companies who "saw the light".

------
michaelochurch
Accept that software is not a meritocracy. Not even close. The politics are as
vicious as in any other industry. You want to know why that idiot is calling
technical shots while you're downwind of the complexity that he imposes?
Because he played the game, and you didn't.

Now, the good news is that most software companies are running at about 5%
efficiency. Most of the code they have exists to serve dipshit requirements
that aren't necessary and make no sense. It's junk complexity that no one
would miss if it were gone. Why is this relevant? Because if you're putting 8
hours per day into order-following grunt work, you're an idiot. Do that, and
of course you'll have no time to work on interesting stuff. The way you get a
better job is to spend at least half your day learning the skills that you'll
need to get where you want to go.

Treat it as an optimization problem. You want not to get fired. That's one
constraint, but not a tight one because a lot of people keep their jobs for
years while doing very little. Your objective: you want a better job in a
year. Are you going to get a better job within the same company, doing more
interesting work? Or are you going to leave for an external promotion as soon
as it's viable? No one is going to know if you put side-project
accomplishments on your resume, so you should.

Most people only "look for work" when they're in shitty situations. The rest
of the time, they either (a) coast, or (b) put their all into their assigned
work because they "really believe in the company". Both of these extremes are
ridiculous. Always keep an eye open for something better, and start your
search process when things are going well, not when they've gone to shit,
politics have turned against you-- note, 95% of firings are about politics,
not "performance"; that's an attempt to use middle-class guilt to prevent a
fired employee from seeking legal recourse-- and you've lost your confidence.

You need to be selfish, because no one will look out for your advancement.
Treat well the people who treat you well. Find ways to read machine learning
books at work. (Don't open a book at your desk; that's political suicide. Get
an e-reader or PDF.) One thing: don't write any code that you care about
owning using company resources or "working time". If you want to turn a side
project into something salable, get up at 5:00 or dedicate your weekends. It's
not worth the risk.

So yes, the disgusting truth is that 90% of the work you'll be assigned will
actually hurt your career. This is why, in most jobs, you should be putting
just enough into your assigned work to get by, and using the surplus for your
own advancement.

By the way, most of the work going on in the corporate "big guys" is junk as
well. Yes, there are people at Google and Amazon who get to work on cutting-
edge machine learning algorithms, but most people at those companies don't,
you'll almost certainly not get such work in your first year, and the politics
you have to navigate to get onto those projects will disgust you and, if you
succeed, make you a worse person.

One solution would be only to work at open-allocation companies like Valve,
but in 2012 there aren't that many of those yet. There will be more in the
future, as they outshine the closed-allocation dinosaurs and starve them of
talent, but that will probably take 10-20 years.

For the mean time, you have to learn to fight. One of the problems with most
career advice sites is that they give AFC advice instead of teaching Game. The
people who get to work on the good projects are those who figure out how to
control the division of labor. They found a way to make people trust them
"prematurely" and gained enough influence over the division of labor to have a
niche. It's not a trivial thing to do. You'll have to go far out of your
comfort zone, learn some social skills you might have been weak in, and it
will take years. Right now, though, I don't see any other option.

~~~
fab13n
> software is not a meritocracy [...] The politics are vicious [...] why that
> idiot is calling technical shots [...]? Because he played the game, and you
> didn't.

Dilbert-style ass-licking and treachery is one way to play the game; being
indispensable because you solve unsolvable problems is another. It is, by
definition, the hacker's way.

It's tricky indeed because it requires a healthy dose of insubordination. A
healthy company is a company which can be operated by real, i.e. mostly
average, people. Big companies are optimized not to depend on individual
genius, although they sometimes pathetically pretend the opposite. If you want
to impose your better but non-standard solutions, you'll have to build them
stealthy, them shove them down the middle management's throat when they
painted themselves in a corner with the standard ones. Your way _might_ solve
the problem, and it _will_ get you disliked by anal-retentive and insecure
managers; move away from them, or make sure that you become indispensable
faster than you become irritating to them. If you pull it off, they'll help
you move away from them anyway.

~~~
mgkimsal
"being indispensable because you solve unsolvable problems is another. It is,
by definition, the hacker's way."

Those problems are 'near' insolvable often because clueless people were in
charge making decisions they shouldn't have been allowed to make. By rescuing
orgs like that, you run the real risk of being relegated to perpetual clean up
guy, and you bolster the decisions.

Rough example: System X was built so badly because of bad directives, that
it's taking 3 hours for a report, and you need 10 reports per day, but you can
only do 8 (8x3=24 hours). Every current employee and 2 outside consultants all
say "this can't be fixed", not because it _can not_ under any circumstance be
fixed, but the cost/benefit doesn't even come close - it's a crappy bandage at
best.

You, being "indispensable super dev" work overtime for 3 weeks to 'fix'
things, and reports are now 15 minutes (like they should have been). Great -
you just 'solved the unsolvable'. Whoop. You've perpetuated the bad decision
making process, and it will be months or years before there can be real change
in the org now.

Being 'indispensable' also usually means you're tied to crap projects and will
never get moved out of that department/division in an upward capacity - you'll
have to quit that company to get any real advancement.

~~~
fab13n
> By rescuing orgs like that, you run the real risk of being relegated to
> perpetual clean up guy

You're right, it's a serious risk and you have to address it. Again, being a
good, "straight A student" who does what he's told when and where he's told
will harm you. You have to know to be bad at what you don't want to do, and at
doing stuff a way you consider broken. There's a delicate balance to find
between being recognized as valuable, remaining manageable, and not being
threaded on. You need to be bad enough that people will try to avoid giving
you that sort of shlep in the future, but it must not come off as insulting,
and it must not be mistaken for incompetence.

The key point to keep in mind that dumb submission might save you a lot of
flak, but will get you neither consideration from anyone, nor better work
conditions. Know when to break the rules, and how much breaking you can get
away with. You can't hack software in a company if you can't hack the company
itself.

