
Coding is boring, unless - jordanfish
https://blog.enki.com/coding-is-boring-unless-4e496720d664
======
binwiederhier
> You can rewrite it from scratch, using a different language or technology.
> This way, you learn something new rather than patching legacy code. And if
> your architecture doesn’t allow this yet, you can take steps to improve it,
> and learn some devops skills in the process.

In a professional environment, we develop software not because it's fun, but
because it supports the business and/or because it is the business. The
primary purpose is to make money and to pay our salary. Now, that doesn't mean
that coding can't be exciting or that you're not supposed to have fun. Not at
all. But I feel that the author largely fails to see the business perspective.
Rewriting things from scratch, adding another language to the overall
architecture, using some fancy new technology, etc. are not wise business
decisions in /most/ cases. Especially the comment about "using a different
language or technology" will lead to a maintenance nightmare in the future ...

~~~
iopq
It's a wise decision if you care about engineers being engaged and liking
their job.

~~~
binwiederhier
I've seen these types of projects where a few developers just went overboard
with all the new frameworks and languages. Two years or so later most of them
have moved on and other devs are stuck with technologies that are now
considered outdated. Especially in the JS world, that's a real scenario.

I am all for keeping your engineers happy. Heck I am one of them. "Exciting"
can mean "better architecture" or "extensible", but I think that adding a new
language is always a bad idea.

~~~
marcosdumay
> other devs are stuck with technologies that are now considered outdated

Isn't that a case of not letting developers rewrite anything? How did it got
so outdated?

Anyway, the Javascript world sucks. Frameworks shouldn't get outdated in just
a few years, and any tech where they do is doing something very wrong.

~~~
frostmatthew
> Isn't that a case of not letting developers rewrite anything? How did it got
> so outdated?

If you're writing (or rewriting) using whatever's hip/new there's a good
chance it will be "outdated" within a few years. New languages and frameworks
come out all the time and nobody is able to determine with certainty which
have real staying power - but something that has been in [wide] use for 10+
years is much more likely to still be widely used ten years from now than
something that just came out last year.

Think of it like music, people have been listening to Mozart for _centuries_
\- it's highly likely a hundred years from now people will still enjoy his
music. It's a lot less likely they'll be listening to Taylor Swift (nothing
against her / her music - just using her as an example of someone who's very
popular right now).

~~~
marcosdumay
There's also a chance writing your project on that 10+ years old platform will
cost you enough time/money to write it three times in a more modern one.

Well, you sound like somebody who I'd agree with most actual decisions about
this. But I do disagree with the overall position. Holding down too much at
"it works, don't change" has actually worse consequences than adopting
immature frameworks all the time. That's not exactly like music - software
tools do get old.

Good platforms, of whatever age normally last for a long time and should be
safe. But if for some chance one didn't last, one shouldn't be too resistant
to replacing it (piecewise and slowly), because the cost of not doing that is
just too big.

------
hibikir
I've been programming professionally for 15 years. But I cannot say that I was
ever bored programming.

My favorite story about this comes from my first job, in 2000. We were working
in C++, and we were turning a program designed to run in one machine into a
client-server system, because nobody made machines big enough to run what we
needed. The plan to do that involved replacing the old function calls with
code that serialized the data, sent it over a wire, deserialized it on the
other side, and call the actual function. In essence, a small bit of smart
code, surrounded by a lot of boilerplate, slightly different for each
function. Months of boredom looming for a team of 5.

But I said: Why do all that serialization and deserialization manually? What
If I can just read the headers for the function calls, and generate the code
that would run it all? Way too hard, our dev lead said: It'll take us longer
to write a code generator that read C++ header files than the months of
boredom. I disagreed, and asked for two weeks of my time to show it could be
done, with less bugs than if we did it by hand. And then when functions
changed, all that we needed to do was add a step to a make file, to regenerate
the whole thing. Ultimately he decided it was OK to let me try. After all,
nobody expected any real output from the guy right out of school, and failure
might teach him to respect his elders.

But it was all done in two weeks, by one person right out of school, because
building a lexical analyzer,a parser, and a simple generator is easy. Instead
of a team bored for months, we had fun work for two weeks, and then on to
better things, without that dev lead.

So if you are doing something long, and slow, and boring, always wonder: Is
there a way to just eliminate that entire set of boring tasks? You'll be
surprised by how often, the answer is yes.

~~~
gjvc
what happened to that dev lead?

------
wpietri
This is missing my biggest trick: one of my biggest ways of fighting boredom
with code is focusing on _meaning_. E.g., if I'm building a system to serve
particular people, I meet them, I visit their offices, I watch them work. I
also like watching user tests and taking support calls. Even when some
particular block of code isn't technically fancy, I'm not bored by it as long
as it's of use to people.

Of course, once you start doing this, you're not really a "coder" any more,
you're somebody who uses code to solve problems for people. This doesn't fit
neatly into some managers' pigeonholes, but I think it results in much better
products, so I'm ok with that.

~~~
chemicaloliver
Yes, so much this... I like new fancy stuff as much as the next guy but I'd
describe my motivations as 'solving other peoples problems with technology'.
That can be done just as easily in a legacy codebase as in a greenfield
project.

------
ggambetta
> _Because 50% of my code (hyperbole intended!) was a direct copy /paste of
> Stack Overflow. And another 40% was a copy/paste from other scripts. Either
> my colleagues’ scripts or my own. It became repetitive. And there was little
> creativity or learning involved._

How is this even possible? I've never had a job where copying and pasting code
would have helped. It blows my mind every time I read this kind of claim, to
the point that I sort of refuse to believe it's true. Are there people who get
paid to do things that simple that they can be copied and pasted from Stack
Overflow?

~~~
gotchange
It always amazes me that there are people out there willing to hire and pay
full these type of workers who scour SO for answers without working hard on
the problem and expanding their knowledge and expertise in the process.

No wonder that our field and profession is suffering from bad image and
quality problem when so-called pros copy and paste all the time on the job.

~~~
sohcahtoa
I think there are two ways to view what the job most programmers do is. IMO it
isn't to write code, it's to solve business problems. Code just happens to be
the tool that you use to do that, most of the time.

Anyone who tries to solve a problem by staring hard at a blank piece of paper
instead of just googling the answer is not making effective use of their time.

~~~
lubonay
You are missing the forest for the trees. Reaching for Google and SO as your
first impulse when confronted with a problem will deteriorate your ability to
find your own solutions in the long run. Use it or lose it, as they say. And
besides, any non-trivial problem can't be solved by copying code from SO
alone.

~~~
TeMPOraL
Most companies don't solve non-trivial problems. For instance, 90% of web
development is regurgitating the same CRUD for different customers. Most of
the work consists of wiring standard components together in a standard way,
and slapping some CSS on top of it. If you're trying to think too much and
reinvent too much, you'll waste a lot of time.

Source: did too much webdev in my life already, and wasted _way_ too much time
doing things by myself.

~~~
gotchange
> For instance, 90% of web development is regurgitating the same CRUD for
> different customers.

Maybe on the face of it, it looks like this to you but in reality it's bit
complicated esp if you're aiming for more differentiation from your
competition but if you're looking for just cookie-cutter, run-of-the-mill,
copycat solutions, then all the products on the market definitely look the
same.

~~~
babuskov
You are both right. 90% of the websites on the Internet do look the same. You
only have 10% (probably even less) products that are special and noteworthy.

------
orthoganol
This is yet another trend following startup employer who doesn't get it.
Really good, seasoned talent wants personal freedom (or more money and
equity), and having an 'awesome culture' doesn't have to do with that.

Culture baits are primarily for 20-somethings out of college who don't know
better or have nothing better to do. An example of giving developers real
freedom: Let them work remotely for n months out of the year.

Yet few will trust developers with real freedom, because it seems too
dangerous to most SV startup employers... and there is certainly risk there...
But baiting developers with video games, pub trips, and secret cinema is just
an extension of constraining said developer's freedom. If they don't care
about that freedom, they are either young, in a tough financial position, or
aren't top talent.

------
S_A_P
I don't know. I've been writing c# for years and I still go to SO for things.
Sometimes it's even stuff I should know, like creating a text file. However I
don't do some of these tasks often enough to remember by heart and it's not an
exciting problem to figure out so I go for SO. I don't see a problem with that
at all. I also don't get the sentiment that you're not a real coder if you use
SO and copy paste code. I don't always have the luxury to figure out which
sorting algorithm is fastest for the dataset I'm working with. Sometimes I
have to meet a deadline. A great developer is one who writes easy to parse
code that is as bug free as possible in the alotted time frame. There are
times when it's important to do some r&d and learn more, but there are also
times when you need to ship. It really depends on what the task is. You can't
paint the whole thing with broad strokes.

~~~
nilliams
Way I read it the overuse of SO (along with C&P programming) thing was just
one example/potential symptom -- he wasn't making a broad generalisation that
all SO usage is bad.

~~~
thebouv
I tell employers and employees and co-workers: I'm a good programmer, I'm a
phenomenal Googler. I don't have to memorize the best sorting algorithms or
how to create a text file in every language I touch. I know how to problem
solve, choose the correct tools and search for guidance (note: that doesn't
mean straight c&p always but could if it is appropriate) on things that get
sticky.

------
to3m
I hope that's somebody's living quarters in the photo, and not their office!
I've worked at a couple of offices that felt tightly packed, but they were
nothing by comparison to that ;)

As a long-term proposition, I'd say that table is suitable for no more than 3.
(Not sure what official guidelines are, but I'd say you'd need around 150cm x
75cm, or 5' x 2'6", per person. That gives you enough room for keyboard-
laptop-monitor depthwise, and two monitors-plus-space widthwise. But the more
the merrier, of course... humans are social, but not THAT social.)

~~~
vinay427
>I hope that's somebody's living quarters in the photo, and not their office!
I've worked at a couple of offices that felt tightly packed, but they were
nothing by comparison to that ;)

That looks like a typical university hackathon to me. Certainly not excusable
if it is an office. Thankfully my only workspace (at an internship) had nicely
sized desks for everyone, and the company was looking to expand by renting
more office space rather than decreasing desk space.

~~~
TeMPOraL
I've been to the offices that look like that - I always assumed it's a typical
startup setup. Frankly, I probably wouldn't last more than a week in such
conditions - I don't respond well to sharing personal space with other people
for prolonged periods of time.

~~~
walshemj
And doing serious development on lap tops realy! you need some decent 2 or 3
monitor set ups with a nice i7 workstations with some nicer mechanical
keyboards and mice.

Yes I know you can get docks etc for laptops but its far more expensive for
the same performance.

~~~
throwaway999888
Just for ergonomics alone you should use a desktop setup over a laptop setup
for any prolonged periods. It's as good as impossible to use a laptop and not
be hunched over.

~~~
Drdrdrq
Or you could use a docking station with proper keyboard, mouse and monitor(s).
Works great if you also need to attend some meetings or conferences from time
to time.

Also, as a developer I don't need i7. SSD, great monitor, keyboard and mouse,
and lots of RAM, yes - but CPU? Depends on domain I guess.

~~~
throwaway999888
> Or you could use a docking station with proper keyboard, mouse and
> monitor(s).

Proper keyboard, mouse and monitor(s) setup is what I meant with "desktop
setup". Of course whether the actual computer is inside a laptop, inside a
desktop cabinet or inside a phone does not matter for ergonomics.

~~~
walshemj
But its more expensive and wastes share holder money and I say that as one who
has been give a written warning for going on strike.

------
overgard
I agree with most of the management advice here -- addressing employees
engagement and boredom is probably one of the most important things you can do
as a manager, and often the fix is simple (new project, new responsibilities,
whatever).

That being said..

You know that old saying "if you're bored than you're boring"? I think most
programmers that like programming are able to keep themselves entertained most
of the time, if they feel like they're building something useful. Even things
that seem mundane often have their moments.

In my experience as a programmer, my engagement almost has nothing to do with
tech stack or stale technologies, it has to do with how useful I think the
project is, and how much decision making autonomy I've been given in my little
zone.

I get the impression with there being a new in-vogue web framework every three
months and database and whatever, that people are just seeking novelty.
Programming has become much more democratized in the last decade, which means
a lot of people that wouldn't have otherwise been programmers are involved.
That's mostly a good thing, but it makes me wonder if a lot of this novelty
seeking is because not-particularly-challenging work is being assigned to
people that are not-that-interested.

------
asveikau
Reads like a whiner to me. Gets bored and switches jobs every two years?
Doesn't want to maintain anything not written by him when he can rewrite it?
These are immature attitudes. I bet his rewrites introduce a ton of new bugs
because he hasn't taken the time to understand what the old thing did.

~~~
jschwartzi
Why? I'm bored with my job. What is missed is that you get bored with a
company because they're treating you like a fixed resource. You get assigned
tasks in your area of usefulness, which everybody takes for granted because
that's all they've ever seen you do.

You ask for time to do useful things like work on the build system or refactor
some stuff to use a new language feature, but because your boss is
uncomfortable letting you branch out, they ignore you. You might get assigned
some busywork documentation while all the real decisions are made after hours
and with no input.

Essentially, you get bored with a job for the same reasons you get bored with
an SO. They slip into a state of taking you for granted.

------
edw519
OP claims:

    
    
      Too Long; Didn’t Learn
      Maintaining legacy code is boring.
      Copy/pasting is boring.
      Internal tools are usually boring.
      Being a code-monkey is boring.
      The day-to-day always gets boring.
    

These things are usually true when you're not building something cool and
meaningful.

These things are rarely true when you ARE building something cool and
meaningful.

So...

 _Coding is boring, unless…_

You're building something cool and meaningful.

That's pretty much been the way I've always seen it. Take OP's 6 headlines and
add all the other stuff like:

    
    
      workspace
      equipment
      boss
      commute
      money
    

and I still believe that if you're building something cool and meaningful, you
put up with everything else and if you're not, you'll find a million things
you don't like.

What you build is the issue. Everything else rest are details.

~~~
dmethvin
> Coding is boring, unless… you're building something cool and meaningful.

The problem comes when the people doing the coding don't consider the
_business goal_ of the software to be cool and meaningful. To everyone but the
programmers, it doesn't matter what tech you use to build the solution if it's
not solving an important problem.

So they start writing a web app with Backbone and then move to Angular and
finally React without ever have created a viable product, but they feel good
because they are using something that other devs feel is the coolest and most
meaningful _today_.

------
anonyfox
I switched jobs a year ago: from a low paid startup job to a company that does
project-to-project grunt work for local banks.

I (@Hisako1337) learned _a lot_ during the past years, absorbed the whole
mindset of Lean Startup, Customer Development and truly agile software
development. I taught myself the complete fullstack, from User interviews to
SPA frontend dev with advanced SEO, backend development with imperative, OO
and functional mindsets (Love Elixir currently!), using different
communication protocols (have a degree in distributed systems), and optimize
solutions by using appropriate database solutions, from relational to document
stores to graph databases. I even learned how to build desktop apps with web
tech before it was as cool as today and currently I absorb every piece of
machine learning material I can find/buy. Every bit of learning happens in my
spare time, because: ...

Now guess what I do for a living for my current "FinTech" employer? Bugfixing
a decade-old Spaghetti-architecture CRUD PHP app, doing pretty useless
projectwork for customers (middle bank management).

I'm not allowed to improve things, because stuff might break and of course
there are zero tests written. Boredom? _I hate every Single hour at work_.
Most colleauges behave like braindead zombies. But the salary is quite good
and I can't move to better job locations.

Others here might not believe that situations like described in this articles
occur- but really- things can be fairly worse. I'd love having problems that
are worth a question at SO, not the trivial gruntwork I'm supposed to do all
day, with zero impact for anyone for idiots that have no clue but enough
money.

Sorry for the rant- this article triggered a wave of emotions...

~~~
khaannn
This is my life. The ancient codebase that doesn't use Objects because "They
didn't see the point" with no unit tests. The pay is more than I could
possibly hope to achieve at another employer in this area and, accounting for
the cost of living, more than I could hope to get anywhere. I'm attempting to
improve the place from within, but the long-term employees are resisting
change.

------
VLM
I'd agree with most of the article except the "The day-to-day always gets
boring" segment. If you don't like yourself, traveling merely results in not
liking yourself somewhere else. If you are boring, going somewhere exciting
merely results in an exciting place now including qty one boring person. If
you don't like your job, being forced to participate in a hackathon will
result in increasing the hatred of the job not loving it. The diversity part
especially was racist, all brits are the same, all greeks are the same, there
is more to diversity. Note how that section also neatly excludes all potential
employees with social lives or family lives outside of coworkers due to the
relatively intense level of required coworker socialization, yet categorized
that very exclusion as diversity. This is especially striking on a holiday
weekend, I had a lot of fun this weekend without a single coworker being
involved, not even a phone call, so far anyway. It would suck from a stress
standpoint never being able to get away from work, or having to give up
holiday family time just to put food on the table.

An unmentioned advantage is there is some (ugh) synergy in the two separately
described issues of elimination of giant monoliths and rotation of personnel.
However, eliminating "can grok the entire system architecture" as a
precondition of writing code doesn't mean nobody needs to grok the entire
system architecture.

One way I've handled "Too Long; Didn’t Learn" professionally is to just fix
stuff on a higher level. In the article there is an example of a boring inside
tool acting as a "fake-Spark". Well why not just re-implement in Spark? The
reason why not might tie into the other paragraph that paraphrases to
"micromanagement is not fun", but just job hop until you find a professionally
managed company then its all good.

------
rifung
I think it's great that the author tries to address high turnover rates by
trying to make the company a fun place to work. However, I feel like he's
taking the wrong approach.

It's certainly true that developers want to have fun, but I don't think
technical decisions should be influenced heavily by what's fun but instead by
what makes sense. For example, it'd be a lot of fun to rewrite an entire code
base in Haskell or some other language I'd like to learn. I'd very much enjoy
working somewhere that I could do something like that. On the other hand I
wouldn't recommend doing that ever, because it makes very little business
sense.

In my opinion, a much more reasonable approach to letting developers have fun
is to give them more freedom in things outside of work. This could be giving
them more free time (every other Friday off or something), or even letting
them do personal projects to advance their skills on company time. For
example, you could host tech talks where employees teach each other things
they learned, and also give them time to learn new things, while on company
time.

This seems to work better to me because this way your developers have a reason
to stay: they will have a hard time finding another company that gives them
these perks. On the other hand, you can keep your company's technical
decisions influenced by what makes sense as a business.

Maybe I'm just very cynical, but work is work, and I understand that while
working I need to do what's best for the company, not for myself. In the same
way, your employees will stay if staying at your company is what's best for
them.

Nevertheless, it makes me happy to see a company that tries to make its
employees happy. I'm just worried that this method isn't really sustainable
for the business itself, and if that's the case then I don't think other
companies would follow suit.

~~~
nickpsecurity
I think there's something to be said for the Google model where you combine a
good work environment with a time-splitting technique that allows a break from
main projects. Many top projects in the company started as someone's 20% time
or whatever they called it. Far as the perks, we don't have to go far as
Google but a subset could certainly help.

------
dannypgh
I don't understand how good programmers can have boring work.

Any work you have that's not interesting is work that should have be done by a
computer for you. If your computer can't trivially obtain and solve the work,
the interesting work clearly isn't done.

Just using tools or applying well-known solutions to known problems is boring,
sure. But that's operational work. I believe our job is to eliminate
operational work by building better (at the omega point, fully automated)
tools.

~~~
dannypgh
Let me walk back that a bit - there's an exception. A good programmer can have
boring work if their managers forbid them from building the tools necessary to
reasonably do their job. I had a job once that did exactly that; they were
happier with the status quo because with the setup they had they needed N
hours of programmer time for every customer-feature launch pair. When I showed
them how we could reduce it to approximately N hours of work to add the
feature to every customer's instance, I was told no, because as it those N
hours spent on each client's site were billable hours to the client. In other
words, that I was reducing the total work needed by a factor of the number of
customers to provide the same value was seen as detrimental to the business.

Their business model was broken to the point where it favored operational work
over engineering work. Hours spent working were more important than results
delivered. I was only at that job for a couple of weeks; pretty much exactly
when they told me that they didn't want me to reduce my total workload because
of their billing structure was when I decided that I'd be leaving. And I have
zero regrets.

So, allow me to rephrase: I don't understand how good programmers, given the
autonomy they ought to have, can have boring work.

------
lordnacho
How does salary come into this? You'd think people would be able to stand the
boredom a bit better if they got paid more.

For instance, I know people in banking who are getting 1200GBP a day doing
nothing special in some Java CRUD. But it's not that easy to find something
interesting like what you read about in startup land that pays nearly as much.

~~~
osullivj
Blimey! Who's paying 1200 for Java CRUD? I get plenty of agent calls for
London banking gigs, and 700 is the top end I tend to hear.

~~~
lordnacho
Well the agent eats a fair chunk. I suppose you need to be somewhat senior as
well.

Figures are quoted to me by a PM who oversees some devs in a well known Swiss
bank in Canary Wharf.

~~~
osullivj
Thanks. I have seen four figure contractor rates at a well known British bank
on CW for senior team lead devs. And I've got first hand experience of four
figure rate cards as a consultant with a "boutique" consultancy myself. I know
that day rates for Python contractors at banks and hedge funds are healthy
recently as I get a lot of agent calls. I guess it's an effect of two things:
firstly, a lot of the banking work is driven by regulation, and so is really
boring. Secondly, lots of startups drawing the best devs with decent salary +
equity.

------
hox
> A key ingredient here is diversity

And all of the employees are white men. Yep.

And what evidence is there that this advice is sound? The company hasn't been
around for the same length of time that the author says is usually when he
gets bored. This is just his rambling train of thoughts on the matter, and
what is important to him.

~~~
dham
> The company hasn't been around for the same length of time that the author
> says is usually when he gets bored

This is the problem with some people. They worry so much about the latest
technology that they forget to just get stuff done. The company might not even
last long enough for engineer turnover. Just do things instead.

------
krick
Off topic: I don't know a single feature that would be as annoying as fucking
toolbar/header/whatever showing up when you scroll upwards. Why everybody does
this?

~~~
arm
I agree, although, it’s not as bad in this case. I find it far more annoying
on sites where the header is always there, as it breaks page down / spacebar
functionality (when you page down, the header will cover some unread text).

------
daxfohl
This doesn't work in the long-run. I'm an independent consultant and when I
was just starting out I had the same thoughts. And it was great to be in full
control and always use the latest shiny new things.

However I eventually got _shiny new_ fatigue. In the long-run, the _real_
thing I found motivating was completing valuable work for clients in the most
efficient way possible.

And perhaps that's the true reason OP has found coding boring in the past. Not
because of anything he thinks are the reasons, but because he's worked at too
many places with inefficient management and poorly-defined projects. If so,
new-shiny is only a bandaid on the root problem, and the real solution is to
ensure projects are well defined, understood to be useful, and well-managed
before a programmer ever even sees it. New-shiny may make it even worse in the
long run.

AND... _microservices???_ I can't imagine a scenario where the benefits
outweigh the cons for as small a team as he's got. Of course they're all the
rage and people get into microservices for all the wrong new-shiny reasons,
but _escaping boredom_ has to be the worst one I've ever heard.

------
jasim
> In our team, we try and prevent anyone from working on the same code,
> product or dataset for more than three months. This period is a bit
> arbitrary and perhaps too short for larger companies. But we generally
> believe in fast rotations.

To contrast, here is Rich Hickey on Mastery:
([https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb](https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb))

A wide variety of experiences might lead to well-roundedness, but not to
greatness, nor even goodness. By constantly switching from one thing to
another you are always reaching above your comfort zone, yes, but doing so by
resetting your skill and knowledge level to zero.

~~~
LoSboccacc
TL;DR: "I work at a startup that provides aids for learning new things aimed
at developers. Here's a 1000 words advertisement."

It may very well loving learning as a person, but the whole pice is incredibly
onedirectional and single minded.

What about build automation? Testing? Deployment of all those unrelated
technologies?

What about every line of code becoming "legacy" in six month?

------
dham
I really want to build a team someday like this. [https://medium.com/s-c-a-
l-e/github-scaling-on-ruby-with-a-n...](https://medium.com/s-c-a-l-e/github-
scaling-on-ruby-with-a-nomadic-tech-team-4db562b96dcd#.i4zbftv4o)

or Shopify.

I think it's possible on a Ruby or Python stack. Yes Ruby was a flavor of the
month but now its not. I feel like if I hire a Ruby guy/girl now, they might
have done it for a while or at least they don't seem to chase technologies.

If I built a product on Node, or Go I just feel like that person would be gone
in a year when the next thing comes out.

I'm sure it happens on the Ruby/Python side but I think probably less.

------
huuu
For me boredom hits when I'm working on some kind of 'not changing the world
in a positive way' project.

I believe every project has it's boring parts. But when the goal is positive
it helps to get thrue.

------
charlieflowers
The business exists to make a profit, and it needs to perform financially as
well as possible _this quarter_.

That does not always align with what is most interesting for a developer to
pursue.

So in the short term and medium term, these goals are usually at odds. In the
long term, you can find harmony between them sometimes if you try really hard.

It's impossible by definition for them to be in harmony all the time. Too bad,
but that's reality. Each individual developer has to occasionally re-align
them by making a job change.

------
logn
This is great advice. Much more important than free pizza and foosball.

Regarding re-writing micro-services, I would be interested to hear how this
turns out for people in practice and how 'micro' these services are.

------
nitrobeast
Fixing bugs in poorly designed/written code is the number one cause of
unhappiness for me. Maintaining my own code is fine, at least it is a learning
process to see what worked/didn't work in the original design. Instead of
letting everyone rewrite the legacy code with a new language/framework, I
think the solution should be that each developer needs to maintain the code
they write as much as possible. Maintenance work should be properly rewarded
and project ownership should be promoted.

------
ercu
>A key ingredient here is diversity: hiring people with different backgrounds
and origins (e.g. our team of 6 is currently British, French, Russian and
Greek). Seeing the same people every day is definitely more interesting if
each of these people can brings something different to the culture.

That is why remote work exists, so you can change your working environment by
traveling to different places and then learn different cultures. That keeps
you away from getting bored.

------
douche
That photo of six people stacked up working at one conference table, almost
jostling elbows, looks like hell on earth for a working environment.

------
known
> As a developer, I never managed to stick to the same job for more than two
> years.

Ditto here.

~~~
lcmatt
2 years > 3 years > 1 year > 1.5 years > 1 year

Just started a new job last week too, some cases its been that I haven't
enjoyed the agency others its nothing more than the new company offering
something better.

------
hendzen
As soon as he mentioned working with a boring, large scale data integration
framework with an annoying DSL I knew what company he was talking about.

------
PSeitz
The codebase must be pretty horrible when switching members all 3 months.

------
nommm-nommm
I _love_ working on the same codebase for years!

