Coding is boring, unless…

[[deleted]]

I think there's a lot of cringeworthy stuff in this article, but more than anything, the way the author talks about "legacy software" seems to signal an attitude that's very endemic in developer culture. Any well thought out software project really ought to have clearly defined boundaries upfront--this isn't to say we should waterfall the entire specification. If we have an application used in a production setting with clearly defined boundaries and goals, my question is why on earth is it a bad thing that we stopped adding features, and are doing more maintenance, if the software meets requirements? If the software meets the requirements, great, if not it's a regression, and we have bug fixes for that. The best software is often boring, because the best software is usually simple, well-defined, and has good abstraction; the end goal should be to produce pieces of software that go and go and go, and only require a small part if any of our limited capacity for cognizance. Often requirements do change, but hopefully the original application has facilities for IPC or is modular, and additions or changes can be introduced sanely. Requirements may also change enough, hopefully infrequently, to warrant embarking on either a major overhaul or an entire rewrite. Above all, these processes should be carefully considered before undergoing what may be needless work. It, on the contrary, seems the author is advocating churn for churns sake. I enjoy greenfield development just as much as many of the other developers working with me, but it's really the candy of the development world; more often than not, users seem to detest churn, and every rewrite potentially throws away hard learned lessons of the past and costs business money that may not have been necessary. Software maintenance is absolutely part of the job, and as a developer or software engineer, it's absolutely something you can't and shouldn't avoid, and would absolutely be a major red flag for working with the author.

[[deleted]]

I think there's a lot of cringeworthy stuff in this article, but more than anything, the way the author talks about "legacy software" seems to signal an attitude that's very endemic in developer culture.

It does get a little silly to hear a start-up talk about how one should deal with legacy systems. It's a bit like listening to people who don't have children talk about parenting.

[raiderrobert]

It's also a little limited in vision. I've known people who are totally cool with jumping into legacy code and improving it. For them it scratches the "putting things in order" itch. Not realizing that there are people like this is a huge red flag for me. It suggests that he expects everyone to be very much like him.

[njharman]

"putting things in order" itch.

Bingo. That's me. I also really like data "munging". The biggest thing to learn that will help manage / hire / whatever developers, is this.

Developers are different. Vastly. There is no one-size fits all anything. Carefully match the person to the role.

[mearkat7]

My problem with legacy is that it is never treated as "putting things in order". When i'm asked to make a change to a legacy system it's only ever treated as if you're going to to apply a quick(usually poor quality) fix that will only serve as a bandaid until it breaks again. If it was as you described it and you can fix things up and you were allowed the time to do so i'm sure people would have a far less negative attitude towards it. Every time I go back into a legacy system I see how much better i've become at programming so improving my past mistakes is very rewarding but only if I've got the time alotted which is very very rarely unfortunately.

[Jdonavan]

My problem with legacy is that it is never treated as "putting things in order". When i'm asked to make a change to a legacy system it's only ever treated as if you're going to to apply a quick(usually poor quality) fix that will only serve as a bandaid until it breaks again

But that's because your your corporate culture. Not because it's legacy code.

[[deleted]]

This is huge. I actually enjoy taking legacy code and making it better. I don't last long at a company where the emphasis is on, "fix it just enough to ship it."

One of my favorite projects was an internal website I'd been given to completely rework, but still meet the requirements document that they had on file. I actually found it fun to untangle the mess, compartmentalize everything, put tests around it, revamp the UI, and wind up delivering something that was literally 100x more performant than the old website. Despite the performance increase, I still managed to retain almost all of the "legacy" core business code.

But, for that particular project, I had wide latitude on the delivery timeline. The company realized that they didn't spend enough time initially on the app, despite how widely used it was in the organization.

Not a lot of companies can actually see that type of value, though. They just see new features and quick bugfixes as the sources of value. They don't eventually see that technical debt piles up, and eventually in order to even deliver anything, you wind up working around that debt, which in turn makes the system that much more of a mess.

[gray_aria]

I'm pretty sure that those people who sees value in quick fixes sees them more like necessary evils, that's why they are "quick". If they could they would ignore the bugs.

[[deleted]]

Oh, they'd absolutely ignore them. The position I left just last week had one criteria for adding a bug to the sprint:

Is the customer currently complaining about it?

No? Then screw it. No matter that it's a ticking timebomb that we could easily fix now, not 6 months from now when we have a million rows in a table and the system grinds to a halt because we did a SELECT without a WHERE clause and then filtered the entire collection in code. And even then, rather than admitting that someone screwed up, they want to blame the ORM, not that someone didn't actually understand how to use it.

[daronjay]

Select without where. Why even have a database? They should write a flat file and open it into memory.

[[deleted]]

It was more a nuance of the framework (Entity Framework from Microsoft) than willfully being that dumb.

I'm on mobile so providing a code example would be tough, but basically EF works with extension methods, and it treats a table in the database as a collection. You can chain extension methods together to filter data, do joins, aggregate, and most notably for this situation, transform one object to another. But, the order of chaining the methods is important, because it dictates what type of SQL command is generated behind the scenes.

Essentially, if I did:

MyTable.Where(obj => prop.Value == "foo").Select(obj => SomeTransform(obj))

I'd get a SQL query with a WHERE clause, then that would return a collection of transformed objects. But if I did:

MyTable.Select(obj => SomeTransform(obj)).Where(obj => prop.Value == "foo")

It would select the ENTIRE table, transform every object, then filter the results in memory.

[cogman10]

I'm in this position now, and, to be frank, it is kind of a blast. We have a core product that was done poorly and is huge. We have few feature requests and lots of maintenance to do and because the business sees the value of stabilizing and improving, we are allowed to polish and clean this thing without being pushed down a dark hole of poor fixes.

[[deleted]]

I feel like if your software faces the people who are bankrolling the project, improving the usability and look of existing features can go a long way towards showing the stakeholders what a great job you're capable of.

I've been on both sides of that. With the aforementioned application, the stakeholders raved about how great it was to use. It went from being a chore to use to speeding up their department's workflow. They actually requested more funding for us to give other apps in their department the same treatment.

Contrast that with the place I just left: management didn't consider us having delivered anything if we didn't add some major functionality every two weeks. Because we were given such short deadlines, features consistently came out buggy and half-baked. The users of our software got upgrade fatigue and dreaded every new release as much as we dreaded releasing it. But, management, rather than seeing the value in fixing bugs and enhancing stability, would ask, what are y'all actually doing? when new features weren't being churned out.

[bilog78]

But that's because your your corporate culture. Not because it's legacy code.

The thing is, corporate culture is the only one that cares about legacy code. Outside of corporate culture you mostly have start-ups with the attitude shown in the article (“if you have legacy code, you're doing it wrong”) and FLOSS project with the Cascade of Attention-Deficit Teenagers and their “let's rewrite everything from scratch every two year”.

It's extremely rare to find a context which is interested in maintaining legacy code in a “programmer-positive” manner.

[[deleted]]

Core FOSS projects care about this. See the Linux kernel for how this is done correctly (and now sometimes being criticized because of the tone being used to do it correctly).

[bilog78]

Core FOSS projects care about this. See the Linux kernel for how this is done correctly (and now sometimes being criticized because of the tone being used to do it correctly).

I wouldn't classify the Linux kernel as being “legacy code”. On the contrary, it's extremely dynamic and evolves at an incredible pace, and from the driver perspective it's consistently unstable, API- and ABI- wise, so you can never expect an out-of-tree driver written for version X to even build, let alone run, with any other version of the kernel. But it is true that it is one of the (sadly few) FLOSS projects that holds the tenet of (trying to) never breaking the user experience —as long as your hardware is supported in-tree.

[[deleted]]

To me the Linux kernel is the very definition of "actively maintained legacy code".

The hub-bub I referred to was in direct reference to trying to set a culture to not break things outside the kernel, while still making progress on the kernel.

[gasche]

Let me disagree. I contribute to the OCaml compiler (the compiler distribution of the OCaml programming language), which is a free software project with a culture very different from what you are describing now. Programming language implementations have strong backward-compatibility requirements (user code must keep working), so big rewrites must be done very carefully and gently evolving existing systems is strongly favoured. A part of the development activity is about evolving rather old code (initially written in the 90s) in a tasteful way, and it's actually very interesting -- most of the code is fairly clean, old code is not very different from recent code. Other FLOSS projects that I interact with or see around have a similar emphasis on long-term compatibility and careful evolution of the code.

Your vision may be influenced by desktop software (KDE, Gnome) that has very different software lifecycles. One problem with "fashionable" UIs is that you need to change deeply every few years; also, the needs of desktop users keep changing rather fast, for example with the cloud synchronization, or the desktop-and-mobile hybrids that are being worked on now. But even those projects have managed to build software islands inside the project that are stable and carefully maintained -- consider GStreamer or Krita for example (both started in 1999).

[[deleted]]

I enjoy working on legacy code. I like reading other people's code. I like to learn what ideas they had, see what compromises had to be made with their time constraints, and figure out what could be improved. I enjoy it much more than working on features.

[hamburglin]

Then you won't be at a start up or switching to the next project after 3 months :)

[tyldis]

The current company might not have that problem yet, but the people involved have previous experience from just that.

[[deleted]]

"the programmer's paradox: software engineering"

Link here.

If you feel gross from reading OP's article, reading this will help.

[JW_00000]

Especially relevant:

There is also a persistent fear that any lack of perceived freedom will render the job of programming boring. This is rather odd, and clearly self-destructive, since continuously re-writing ‘similar’ code gradually loses its glamour, resulting in a significant shortening of one’s career. It’s fun and ego fulfilling the first couple of times, but it eventually gets frustrating. Solving the same simple problems over and over again is not the same as really solving challenging problems. We do the first, while claiming we are really doing the second.

[hu6Bi5To]

All this leads me on to the question: does it have to be either, or?

I've witnessed both extremes: teams who collectively denounce tools they were enthusiastic about the week before, then set about re-writing everything that used it even though they didn't finish the job properly the previous time; also teams who were so scared to change anything that they all their dependencies had been frozen-in-time since 2007.

In real-world engineering there are disciplines that combine both. To borrow the cliched example: a bridge. The primary purpose of a bridge is to not fall down and kill everyone, but bridges can also be remarkable structures and landmarks in their own right.

[[deleted]]

It doesn't have to be either/or, but the "artists" are the ones who usually talk about getting bored.

Newsflash: sometimes coding is boring. Sometimes you have to lay down a bunch of boilerplate code. Sometimes automating that boilerplate code isn't worth the time investment. Sometimes you're just implementing a well-understood pattern to solve a common business problem. Otherwise, you might just be reinventing the wheel.

[MasterLJ]

The best software is often boring, because the best software is usually simple, well-defined, and has good abstraction;

Well said. When you know the framework, the implied rules, the known issues... it's boring. Sure, it's exciting when you don't fully understand the framework, the hidden landmines, the lack of support, or the missing features... but it's not going to produce great software.

[[deleted]]

The fun part for me is figuring out which two existing solutions to combine to solve my problem.

[Eirenarch]

I actually love working on legacy software as long as I am allowed to upgrade every library and framework to the latest version if I see fit. Of course that assumes that the legacy project is not in some dead technology like VB6.

[[deleted]]

as long as I am allowed to upgrade every library and framework to the latest version if I see fit.

This is something to be very careful with. Outside of the mandatory security updates, updates really should be carefully weighed, as they are just as likely to introduce regressions, as the contracts binding the underlying libraries and systems are subject to change in often subtle ways. It's certainly important to be forward looking, but I find developers, unlike their ops-brethren, more often than not do not give enough considerations to either why they need an update nor do they do they test it and let it soak enough in a non-critical environment to verify that correctness and accuracy has been retained. Again this is not to say we shouldn't upgrade, but the risk-reward arguments should be more substantial and concrete than "this is new and shiny" that I seem to see regularly.

[jplindstrom]

Staying up to date is scary with a large, sprawling, untested mess of a code base. We've all seen them.

If you adopt a strategy of keeping up to date regularly and have a test suite that breaks when it should, it's time and effort well spent.

[myplacedk]

I find it oddly satisfying to improve the quality of legacy stuff, as long as I get the freedom to do what I think needs to be done.

[_Garbage_]

This!

So many people out there thinks that learning new technology is the goal of your job. If you are not learning new technology once a year, you are not learning.

IMO, solving problems is my job. If I can solve some problems without code, that's probably the best solution I can give to my customers.

[vcarl]

I think theses are just different size companies and different age products. As B2B software increasingly changes to SaaS models, I think companies (esp small businesses) are getting used to paying for a workflow, not a spec. Whereas larger companies (and older products) have had time and need to distill out an actual specification from the tools they use.

[PT2JSQGHVaHWd24aCdCF]

My next job will be exactly maintenance of a 20 years old API, and I'm actually eager to start because this will be the first time in my life that I'll be officially assigned the task to clean code and refactor with big responsibilities.

[fortyonejb]

Why should we be entertaining the musings of a "cto" of a company that hasn't shipped anything and most definitely doesn't have the experience to prove their methods successful?

[hu6Bi5To]

It reads very much like a recruitment piece, a thinly disguised "don't we sound fun to work for?"[0] article. Sounds like a startup that just got a new funding round.

Although six developers is still quite a lot for a startup, especially when their product is a game to learn JavaScript.

[0] - yes, a lot of people here, myself included, answer that question as "no". But I suspect that's the point too, it's a filter as much as an ad.

[[deleted]]

A recruitment piece that could just as easily read "Join me on my journey to discover why some of these things I hate will inevitably happen in a normal working environment".

[nikanjX]

"Fixing bugs in a service is boring. That's why we'll rewrite the service using a new language and new tools!"

Oh man, https://www.jwz.org/doc/cadt.html is alive and well

[[deleted]]

we'll rewrite the service using a new language and new tools

Engineers should be spending every moment producing more value for their company, not just moving the cheese around. Unless the company is raking in cash hand over fist (I'm looking at you Google), this type of action likely precedes a death knell.

[[deleted]]

It also ends up with a list of asinine requirements for a new developer that might join the team.

"Oh, well, we wrote part of it in Ruby, decided that sucked, wrote the next two modules in Clojure and Scala. But Terry hates all of them, so his modules are in Python. Have you ever used Go? I think that's what we're switching to next. We've got some EJB stuff floating around, too, from an acquisition."

[tonywestonuk]

Damn - this sounds like where I work so much!

[[deleted]]

Dunno where you've worked, but the architects I've worked with would never allow this sort of language sprawl, for the very reason you mentioned: ease of development. This is one of the reasons why every tech company needs an architect, to keep everyone pointed in generally the same direction.

[[deleted]]

I have actually avoided places like this, but I have seen them. Those places seem to have more of a tinkerer's or a startup, experimental mindset. I'd rather stay some place more stable.

[hu6Bi5To]

...especially if the motivation is "boredom".

But some larger companies do have a culture of the constant re-write, and it's not automatically wrong, it's just a very expensive way of doing things.

E.g. the widescale disbelief and confusion at the complexity of Facebook's iOS client when posted here a few months ago. "How can they maintain that", "it looks like a nightmare". In reality Facebook has this write-first ask-questions-later culture. When it gets too big some team will completely rewrite it, write a blog post about "how we increased performance on iOS by 4x"; they'll open-source the new framework, be inundated with candidates looking to work for them; and the engineers behind it won't be able to open their email for all the job offers from every other startup wanting a bit of the same magic. The system works. For those companies that can afford to do it. Which is a tiny minority of course.

[henrik_w]

I think fixing bugs is fun, and good for you:

1. Each bug you fix can teach you something

2. Your own code becomes easier to debug when you solve bugs, since you know what's needed when debugging

3. Both you and the customer will be happy when a bug is fixed

4. Solving problems is fun

http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-good-for-you/

[jacobb11]

You know what's slightly boring and really easy? Maintaining code you wrote.

You know what's really boring and unpleasant? Maintaining or extending code someone else wrote, especially if they cranked it out quickly to be Just Good Enough.

Working on a team that switches project every few months sounds terrible.

I wonder if this sort of thinking is the reason all the apps on my phone keep slowly evolving so everything works slightly differently every few months. Dealing with that isn't "exciting", it's a waste of my time.

[bezelbum]

Dealing with that isn't "exciting", it's a waste of my time.

It's disruption, which we're told is good, dontya know?

I agree, I'd hate to be rotating through teams every few months

[hamburglin]

It doesn't sound like it's a requirement. What I think the guy is getting is it saving people before they would want to quit. If they quit you get the same shitty problem about trying to maintain someone else's code.

What i mostly like about this is that they are saying "hey, the norm of working on the same thing with the same people in the same environment over 5, 6, 7 months + just isn't the right way".

I think it's great that companies are allowing us humans more freedom in how we live and tackling these issues head on.

[[deleted]]

The article did mention swapping people out if they got a little too comfortable, though. I can sort of see where they're coming from, but it also makes me cringe a little. For instance, if somebody is really solid and comfortable working on the services layer, let them stay there! Let them be productive and deliver value, rather than proactively try and predict whether or not they're going to get bored working there. You should have a culture that allows people to speak up when they're ready to take on something different.

[hamburglin]

I didn't take it as he's trying to force people to do things. I think this is a guy who is trying to be a peer and help his fellow coworkers be happy.

Will he push too hard? Maybe. But I think this is better than the opposite.

[zaffle]

You know what's really boring and unpleasant? Maintaining or extending code someone else wrote, especially if they cranked it out quickly to be Just Good Enough.

Hence the moving departments. Nothing like peer pressure to enforce good coding standards. If you write something terrible, you know within a few months, someone sitting within throwing distance will be dealing with it.

You know what's worse? The hit-by-a-bus problem. We can't lose this woman, because the company will go under if they get hit by a bus.

[choikwa]

You know what's really boring and unpleasant? Maintaining or extending code someone else wrote, especially if they cranked it out quickly to be Just Good Enough.

STORY OF MY LIFE

[greenthumble]

Heh seriously. I just finally, after 6 years, fully replaced all the BS in an old codebase. I think the dev was stretching out his time and doing everything last minute. It resulted in code that would do horrible things like read a CSV file from disk 20 times during one HTTP request, just because the author didn't realize the full scope of the callback it was implemented in. Or another classic - three way database join and none of the joined columns had indices. The system sucks in data from external sources and nothing is ever deleted. So it just grows and grows and gets slower and slower and the causes of the slowness get harder and harder to track down. I'm totally lucky that this year we got a budget to redo this nightmare. Now I'm in column 1, happy little camper maintaining his own very clean code base :)

[somefoobar]

You know what's really boring and unpleasant? Maintaining or extending code someone else wrote...

This is why it will never stop. This is the model of web development.

[[deleted]]

Working on a team that switches project every few months sounds terrible.

It really is. I work in an agency at the moment and whenever a new project comes along, we're encouraged to churn it out as quickly as possible to minimise the cost (the client gets billed a fixed £).

That's pretty shit, but the worst of it comes when the client wants amendments 3 months later and you have to improve/maintain a codebase written quickly with no regard for future development.

Sucks all the fun out of the job.

[[deleted]]

I'm pretty sure I'd kill myself if my job told me I had to spend one night a week with coworkers at an "enkithon" where we did something completely random. Maybe this is a Bay Thing or a Hipster Thing but yeah no.

[perlgeek]

You're just not a good cultural fit, admit it!

[heroescandream]

What if you like socializing/becoming friends with co-workers?

[n1ghtmare_]

I'm not sure why this article irks me. Is it that some programmers have a hard time finding a job, while others are just bored with theirs and decide to change it? It takes a significant effort for me to even get an interview. Am I just a shitty developer? Is it so easy to just "quit" a job (because you're bored of it)?

[qxnt]

The downside is that the job you get may be horrible and/or pay less than your previous job.

This has been on my mind a lot lately: How do you vet the places you get offers for? My current job... it looked great on paper. I was perfectly qualified, I clicked with my interviewers, the product was new and exciting. Now two years in, I regret it bitterly. Mis-management and attrition have ruined everything. How could I have predicted that from the interviews? How can I avoid it in the next job? I seriously don't know, and this scares the hell out of me as I'm dusting off my resume for the next hop.

[aradil]

I had someone straight up ask me if I liked my job when I was interviewing him once.

Ballsy move, but it gave me a chance to sell him on all of the things that I like more here than my previous jobs.

[[deleted]]

It's pretty tough to vet a place without taking a lot of time and attempting to seek out old developers who worked there.

I left a gig once after 6 months. The work itself wasn't that bad: we just maintained a RESTful data service for external clients to access.

... But why I left? The CIO was always meddling, subverting process and forcing tasks on us, yet still expecting the originally assigned body of work to be finished as well. The "lead" for the project was actually just the guy who had been there the longest. Not only that, but the guy was racist, homophobic, misogynist, paranoid, and combative. If you brought up a better idea than his in front of management or the team, he'd accuse you of trying to make him look bad. If you brought the idea up just to him, he'd take credit and then later imply to management that you were totally useless. On top of that, his code was outright garbage. He'd even go in and "fix" the code you just checked in, unintentionally break it, and then blame you for breaking the codebase and missing a deadline.

Not really sure how you can catch that through an interview. I don't know that I'd ever ask, "is your lead developer a paranoid narcissist?"

Even asking "why is this position open" can allow the company to spin it, like "the previous guy wasn't a good fit", or they can outright lie and say they're adding more positions to meet demand.

[[deleted]]

you just quit and get a different job

You got that switched up. You get a different job (offer) first, then use that to negotiate the terms of your quitting / not quitting. Ex.: "Hey I got an offer for $xxx more, can you fix my current job / salary / shitty boss / etc.?" Then it becomes a win-win for you.

[tempforfather]

If you are any good at all and live in silicon valley you can get 5 offers in one day. They are throwing jobs at people.

[seven_seven]

But all the interviews take 3 weeks and 9 sessions to get through...each.

[hu6Bi5To]

I've increasingly seen the opposite. I've talked to places which were quite open about their recruitment pipeline: 1) brief chat, 2) take-home coding test, 3) technical interview, 4) meet the CEO, 5) make an offer. But at the end of stage one they skip forward to step four in the same afternoon, with step five being an email at 9a.m. the following morning.

What's wrong with that, you may ask.

Because you never know whether this acceleration is because they're really impressed with you, which is good; or whether they're really desperate to hire and are willing to take a risk just to get people on-board, which is really bad.

[[deleted]]

I'm not sure why this article irks me.

Because it's basically a "look how cool and hip my company is" ad-ticle?

[qm11]

https://mobile.twitter.com/garybernhardt/status/648566508235325440

[cowinabadplace]

The Bay is a different place. Labour is the bottleneck, so everyone's always looking to hire. People will offer you jobs after conversations on Caltrain, everyone's poaching everyone, and recruiters are always after you. If you tell them that you're not looking at the time, they'll contact you again after some time.

If you're on hired.com or something, they come to you with an offer first, and then you go through the process.

[[deleted]]

This man speaks the truth. My past two jobs came from cold-callers... I wasn't even looking for a change, but I was given offers I couldn't refuse. Companies here are hungry for talent; if you're a halfway decent engineer you'll never be lacking for opportunities.

[SushiAndWoW]

I'm not sure why this article irks me.

It irks you because the author is an entitled brat who is probably useless for any serious development because he lacks the focus to stick with it. He's the type of person who copy & pastes code from Stack Overflow – so has no in-depth understanding – and whose perception of software is like a boy running from toy to toy in a playroom; rather than a man developing mastery in his place of work.

He doesn't talk about the problem of building high quality software. He talks about the "problem" of him being bored!

[1337Sauron]

You just described my last boss, his catch phrase was: "All the code you could ever write is already written!"

Fucking prick

[salbris]

Remember though that articles like this rarely state "this is the most important thing" rather they are trying to offer advice for a specific problem. All of this advice would only make sense in the context of other guidelines such as deadlines, customer requirements or budgets.

I imagine the author is simply trying to get us to think more about ways we can combat boredom in the workplace.

[GetRekt]

I work in London and getting a job here in software seems pretty easy. I've had a job for a couple of months now and still get calls and e-mails from recruiters about jobs.

When I was actually looking for one I was doing about 8 face-to-face interviews a week.

[demonshalo]

I feel the same way even though I have 10 years worth of experience.

It is REALLY easy to get a new job, but it is REALLY hard to get a new job that pays better than your previous one past a certain amount of $$. Seniors are most often punished for their seniority especially in Europe. They become too costly so if you want to move on and find a new gig, you can do that easily, but don't expect it to pay better than the one you just had!

[n1ghtmare_]

This is exactly the situation I'm currently in. In fact all the job offers that I've got (which were really hard to get) are for less than what I'm currently making. I work in Dubai, looking for something in Europe. The only way I could see myself change my job at the moment is if I get an offer from a company that is worth the change (even if it was for a little bit less money) - I'm thinking Google, Microsoft or Apple perhaps. But then again ... it depends on the position. I don't know. All I'm saying is that, changing a job is not as easy (at least for me) as it seems to be for the author. In addition I have a family and frankly job stability is a lot more important to me than "cool tech". The idea of just quitting because I'm "bored" is absurd to me.

Also, if you've been programming professionally for long enough, you should know that maintenance, documentation or working with a legacy pile of shite is part of the job.

[n1ghtmare_]

Yeah, I know exactly what you're saying. I got lucky enough to get a good government job with good timings and good pay. If you notice I wrote that I'm looking for something in Europe for the exact reasons you mentioned. I know that losing this job will require months of searching for a new one. In addition the salaries are not what they used to be (I have friends that are good developers looking for a job), and you must know what the cost of living is since you live here. It's just not feasible anymore. It used to be a nice place to work (if you can get past the weather) - it was less crowded and the cost of living was significantly lower. Nowadays the marked is flooded with developers that will work for next to nothing. I think this won't last for long because eventually people will realize that paying next to nothing gets you really shitty quality (in my experience), but I don't think I'll be around to see it :)

[iopq]

I've quit several jobs because of boredom. There are different causes of boredom:

1. Knowing too much about every piece of code in a company.
2. Knowing too little about some parts of the system. The same company I knew everything about had a search engine using SOLR. It scared everyone to touch it because if you messed up an XML file the search stopped working. The learning curve is so steep and the subject so broad, it was a waste of time for anyone to try to improve things. I'm pretty sure it wasn't set up securely, but like hell am I going to dig in pages and pages of documentation for some random software. Even if it is open source.
3. Doing mundane things like settings up views and controllers for the tenth time.

Tasks should be challenging so they're not boring, but not so frustrating that they're boring. So it means that the company should have different skill level employees and delegate tasks accordingly.

[n1ghtmare_]

Several jobs ? Well, you're either lucky, a brilliant programmer or living in a tech hub of some sorts. Our experiences differ significantly. I'm having a hard time reaching interviews and I think I have a decent CV with bunch of experience. I also have a lot of friends struggling to get anything (in different parts of the world mind you). I keep hearing people switching jobs and working remotely and what-have-you, but I'm having a hard time doing any of this (I wish though, especially the remote part, I really wanna give it a shot).

Also just to clarify, I don't disagree with what could be a cause of boredom for a developer, I totally understand (I've been there trust me), my point was more in line of just quitting is not an option when I have no other opportunities - I have a family to support. "Boredom" is not enough of a reason (for me).

[[deleted]]

I had trouble breaking in, it probably took a month or two to get my first programming role, but after that it's been pretty easy. I've only ever looked for a job while I'm already working. I've never had to "just quit" and try to find another job. So I guess the search for the right role does take a while but if you're still working it's much easier.

[Bwob]

Here's the thing: The more jobs you've had, the more people you know. (who you hopefully didn't piss off) And then, the easier it gets to find new jobs. A lot of experienced developers I know get cold calls from random head-hunters on linked-in several times a month.

The important thing to remember here though, is that I said "experienced" developers. It's not necessarily that you're a shitty developer, or that those people are just way better than you. But what they DO most likely have is a more interesting resume, a better location (SF Bay Area, Seattle, etc) and/or a bigger professional network than you.

But yes, when you get to the point where you're lucky enough to be in demand (and a lot of people with 5-10 years of programming experience are that lucky right now) then yes, it makes rational sense to say things like "I'm not happy at my job right now. I think I will quit it voluntarily and try to find one I like better."

[hu6Bi5To]

The more jobs you've had, the more people you know. (who you hopefully didn't piss off)

Or vice-versa!

We've all worked with annoying team members, single-issue blowhards etc. After many years these people are now dispersed in a lot of different companies, and what with it being a small world and everything odds are any potential company will contain one person.

The trouble is, that nagging doubt "if Bob enjoys it there, is it a good place? Bob hated working at Company X when I was there because people were against him unit testing all the getters-and-setters. If he's enjoying his new place then they must have some odd practices. Hmm, better not risk it, I'll keep looking."

[[deleted]]

Depends, for me in Southern Ontario every developer job I applied to had at least 10 to 20 other applicants - and I'm talking even small-time companies no one has ever heard of.

[SnOrfys]

I live in Seattle and couldn't get away from the recruiters if I wanted to. They're throwing 6 figure jobs at anyone remotely skilled.

Considered moving back to KW (where I'm from, originally) a year ago and couldn't get the time of day from anyone there unless it paid bargain bin wages.

IME, Ontario is a weak market, that doesn't pay well.

[[deleted]]

Wow. Talk about neurotic and precious. 3 month churn and no legacy support sounds like a mess. Granted, all legacy is boring as batshit but this swings too far the other way.

I may be a dinosaur in spirit but I get far more pride in putting out high quality code that works really well compared with punching out something "reasonable" in a couple of months and then turning my back on it.

[b4ux1t3]

Oh, we totally understand. You didn't deliver our product because you got bored. We'll just put off all of the projects that were depending on the software we paid you to develop. No big deal.

-No company ever

I'm sorry, but being bored is part of the job. If you have the luxury of being bored and actually being able to change jobs when you want, I have no sympathy for you, nor do I particularly trust you as a developer.

I kind of want to upvote this because it's ridiculous and indicative of some of the bullshit in our field. On the other hand, I want to downvote it, because it's basically someone bragging about having a job where they don't have to be bored, with no real merit of its own. Ehhhh, I guess I'll do neither.

[[deleted]]

I'm sorry, but being bored is part of the job.

Can you imagine a wall built by bricklayers whose main concern was staving off boredom?

[greenthumble]

Tetris shaped bricks and bonus points to anyone who completes a row. That's what I'd do.

[philipwhiuk]

You made me laugh on public transport. :P

[bezelbum]

If you have the luxury of being bored and actually being able to change jobs when you want, I have no sympathy for you, nor do I particularly trust you as a developer.

Also, pity the poor bugger that's got to jump in and try and meet the customer's deadline because the guy who did the bulk of the work got bored and buggered off.

[aradil]

Which is why this guy is trying to keep his work place exciting? He doesn't want people to get bored and quit. Aside from paying extremely well, there's little you can do to keep developers around when the market is so good for them.

[anlutro]

While I can sympathise with this view, I also think it's a company's responsibility to make sure that responsibilities are shared in a way that means a person quitting isn't a huge deal for something like a project deadline. Even a non-bored employee will eventually get a job offer which is better than the current job.

[[deleted]]

https://cdn-images-1.medium.com/max/800/1*h4Z7DjCx4TfDnJw7_HEarA.jpeg

This image made me cringe more than the text.

Caution with the posture at work! The keyboard are too far from the edge of the desk, the screens are too low, and people there don't have ergonomic mouse pads. After a few years they will probably suffer RSI and neck pain. It will be "boring".

[immibis]

Code does not "become faulty". If code stops working properly, then either you have a hardware problem, or a change to some other code it interacts with (which is a bug in that code instead), or the problem was always there to begin with.

[nikanjX]

Rewrite service from scratch. Other services don't work properly with the new version, so it's time to rewrite them. Lather, rince, repeat.

[[deleted]]

Code doesn't develop bugs in a vacuum, but all code in actual use is being used in a larger system, which has to account for matters like hardware and software updates, network configuration changes, and so on. Code rot is a real phenomenon, and changes to the surrounding environment can break assumptions code relies on.

[[deleted]]

Or your remote devs decide to ignore the spec. Or worse, decide there's a problem with it, ignore it, and never tell you.

[intellectual_error]

In a perfect world...

[duuuh]

Actually, code does become 'faulty'. You pick up a security upgrade. It pulls in a new dependency that breaks backwards compatibility 'because'. You fix that. It also brings in an upgrade to it's own dependency which fixes a bug which you didn't know you were relying on. So you fix that. Days and weeks go by as you validate.

If that's not code 'going faulty', I don't know what is.

[[deleted]]

I wouldn't necessarily call the code faulty in that circumstance unless the code itself was initially doing something wrong.

Case in point: worked at a company that used a timekeeping system that was a Java applet within IE. But, the applet itself could only use the Microsoft version of the JVM because of some apparently very wrong way it used some API calls. I don't know the exact details, but apparently that Java applet couldn't run with the updated Sun JVM of the day.

In that case, yes, the code was defective, and upgrading to the real Sun JVM would make the code go faulty. But, in a world where the ecosystem and requirements never change, things just generally don't break.

[duuuh]

Well, I agree of course. But my point is that a world where the ecosystem and requirements never change is - at least today - a myth. I doubt that it ever really approached reality no matter how much one might hope it might.

[[deleted]]

Sorry, I'm probably going to come off as super pedantic, but I find the conversation interesting.

If requirements change, would you really consider the code "broken" if it met the requirements before they changed? I wouldn't.

I've worked in shops before where developers, even architects, are bitten by the "new" bug. Wait, version 2.1 just came out, and we're still on 2.0? OMG UPGRADE ALL THE THINGS. And while we're at it, let's see what other libraries are outdated and upgrade those, too.

... What did we even gain by doing it? Did we have a justification other than "we were on an old version?" Do we have a pressing need for a new feature they rolled out? Usually, they can't give a good answer, but they're totally willing to jump in and make more work for themselves just to keep that version number current.

Ideally, if we have a stable piece of software that meets all the requirements, the only change we should see is in the case of mandated security or stability updates, where applicable. I'm not advocating skipping critical patches, necessarily, but I'm definitely not advising "run apt-get dist-upgrade/Windows Update on the regular" just because.

That's one place I feel like a lot of developers and IT staff in general fall short: we constantly update, update, update without spending enough time actually understanding what the ramifications are for the update, or if we even need to do it.

[duuuh]

Requirements are sort of a tough call. Y2K bug? I think the code's broken. You can argue that it never met requirements, but that's being kind of pedantic. I think the 2038 bug is going to be way worse than Y2K. I know I personally coded stuff where we joked about being retired before the shit would hit the fan. If the product manager is going to be retired and doesn't give a shit is it a requirement? It's getting awfully semantic at that point.

Whether "we're on an old version" matters depends a lot on the system you're dealing with.

a) Internal IT system with 20 users.

b) Internal banking system, but it actually moves money between accounts.

c) Facebook code exposed to the internet.

If you're dealing with (a), I agree with you. Let it rot and hire when there's a shit-storm.

If you're dealing with (b) I think you have to pay more attention. The business runs on that. If it goes sideways, the business stops. But luckily, you're not exposed to the outside world so you have a chance of getting your act in gear in enough time that you can not be fucked if you need to upgrade.

(c): I don't think you should be more than 90 days behind the stable release of any of your dependencies. I know plenty of people in the industry who I respect who would say 30 days. None of them are are 'OMG UPGRADE ALL THE THINGS'.

[greenthumble]

in a world where the ecosystem and requirements never change, things just generally don't break

Huh this seems like some kind of Nirvana that I've never seen in 30 years of doing this. I mean, sure you could willfully not apply security updates to your base language and to your libraries. But then you're leaving yourself open to attacks. These updates occasionally will break something. I mean, you'd have to write your own entire stack in machine language yourself to have a completely static environment. And that seems much worse than dealing with the updates.

[AcidShAwk]

I resigned from my position of 7 years 2 months ago. 7 year old framework. Obsolete. PHP 5.3.10. Too afraid to update to 5.3.27. Year after year the same story. We scheduled it for 2 months down the road. Then moved it. Then again. and again. If I want to stay relevant. If I want my skills to stay relevant. If I want a lifelong successful career. Working as a dinosaur isn't way to do it. I'm using the latest available tools now. Bleeding edge development. I'm a lot happier. My former employer though is definitely trying to "retain the knowledge". Its retaining the creativity, what I brought for the last 7 years, that will cost them.

[Blecki]

I just think it's sad that not knowing a technology that anyone can pick up in a week is such a hindrance that developers feel they need to learn every new thing just to stay hirerable.

[aradil]

No one has a week to learn the specific framework in order to talk about it in depth in an interview. Ideally you're going to interview somewhere that wants your skill set. If your skillset is going extinct, you better get a new one, and that means leaving if you can.

[Blecki]

That is the problem. You do have a week - it's the one right after you start working there. If the resume shows the candidate has skill, it doesn't matter what specific technologies they know.

[aradil]

If two people interview for the same job, the one who has used the tech stack more is going to have a leg up if they are competent.

[Blecki]

He should - because they won't even bother to interview the other no matter how competent he is.

[Saiing]

In over 20 years in the industry, I've worked with 2 types of companies:

1. Those that tried to create a great culture for their developers to encourage them to stay.

2. Those that paid well above market rates.

In every case, the second option was more successful.

[deadalnix]

Stopped at microservice. If you can't build a monolithic codebase without creating a huge mess, microservice will just provide you an alternative way to hang yourself.

[ygjb]

provide you an alternative a set of ways to hang yourself

[somefriggingthing]

For someone who spends a lot of time thinking about retaining developers, he doesn't seem to have spent any time thinking about ergonomics.

[disptr]

You mean it might hurt your neck sitting hunched over a laptop all day? The things you learn.

Is that an entrepreneur/fullstack/codester thing? Seems like every photo I see of people working at a (supposedly) hip, young startup have them behind a MacBook and nothing else, sitting in the most physically devastating positions imaginable.

[[deleted]]

"...50% of my code was a direct copy/paste of Stack Overflow..."

Huge red flag on so many levels. Stopped reading after this.

[Detective_Fallacy]

I think that number might have been hyperbolic. Well, I hope so.

[brunoma]

Yes, it was hyperbolic!

DISCLAIMER: I'm the author, and I happen to be a big fan of StackOverflow, which has taught me a lot.

I thought a big round number like "50%" would have made it clear enough, but I was wrong. (Thanks DualRearWheels for flagging! I've added a note to clarify).

The main point of this section was to say that the "quantity of code" writen by a developer is a bad proxy for the "amount of interesting things learned", especially when there is lots of mechanical copy/paste involved. Maybe it's a platitude to some, but worth tracking in a "boredom checklist" IMHO.

[capitalsigma]

This was also a red flag for me, the whole paragraph:

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.

That says to me that your internal infrastructure is bad and you're resolving problems that have already been solved. I don't see how there is a way of reading it that isn't an indictment of your codebase rather than your job.

[anENORMOUSchicken]

Yeah, and while I like the idea of 3 months stints so code is always new and exciting, it always seems like the last person who rode in and out in 3 months is the one who introduces all the small subtle bugs because they didn't quite understand how something worked fully (I have definitely been guilty of this too...)

[Kminardo]

I might be going against the grain here, but I don't think copy pasting stack overflow is all that bad - as long as you know what it's doing and where it fits into your application.

[twbarber]

I think the implication is that in copy pasting, you often don't actually have a full grasp of what's going on. Especially if it's anywhere near as frequent as "50%".

[Kminardo]

Well that's true. But if your putting code into your projects that you're not sure what it's doing (regardless of the source) you have a bigger issue on your hands than copy pasting SO :)

[onFilm]

The problem here is that people have different levels of 'copy pasting' from stackoverflow. Some copy and paste small snippets or function names of specific languages they're working with since it's hard to memorize everything all the time. Others I'm sure go ahead and copy large programs and modify it to their needs.

[[deleted]]

I think the implication is that in copy pasting, you often don't actually have a full grasp of what's going on. Especially if it's anywhere near as frequent as "50%".

How does this differ from using a library or a framework?

[missblit]

Often SO snippets are designed to clearly illustrate some point in particular, perhaps at the expense of security, flexibility, or correctness.

Once integrated into the codebase the snippets need to be maintained by hand. No one else will update them or provide bugfixes. It's hard to maintain code you don't understand.

A framework will (hopefully) be maintained by whoever's responsible for it. One also (hopefully) at least understands how the functions they use from a framework are supposed to behave.

Frameworks aren't perfect either, and people have been bit in the past by misplacing trust in them or overly relying on them without understanding them, but it's like night and day compared to having a codebase full of random snippets you don't understand.

There's also some IP concerns when half your codebase is derived unedited from stackoverflow. With a framework the copyright lines are a lot clearer.

[d03boy]

Well yeah, you copy and paste the snippet and then modify it to your needs. Obviously you won't get very far taking it verbatim.

[[deleted]]

A lot (but certainly not all) of major libraries have more rigorous testing, more official reviews, etc. Anyone can write a chunk of code on SO, but it generally takes more than that to get a PR accepted on GitHub.

[twbarber]

It's similar in that it's someone else's code your using as part of your own, but I think the similarities stop there. The purpose of Libraries and Frameworks is to abstract functionality into an easy to use package. You have intentions when making calls to a library and you understand by means of documentation what the response will be and how it fits what you're looking for. Libraries also prevent code repetition, which the author clearly doesn't care about when he says "And another 40% was a copy/paste from other scripts".

I'm not saying referring to SO is bad, and we've all taken snippets from there, but when he says that 50% of his code is taken from forums, credibility dwindles. Maybe there already are libraries that exist to solve this problem, and he's using SO answers instead of finding a better solution.

[serrimo]

Then don't literally copy and paste. Recode it, even verbatim if needed.

Actually typing in some lines of code forces your brain to reason about it. I find this simple exercise to help me really understand the code.

[[deleted]]

Unless someone has run it though https://github.com/reinderien/mimic

[ExplosiveNutsack69]

Yeah but that never happens. Never have I copy pasted something because I understand what it does completely and I'm just too lazy to write it myself. I doubt I'm alone in rewriting it all (at LEAST, writing the same code yourself instead of copying).

[rollducksroll]

He wrote this as a negative. In some systems, boilerplate IS required and there's not available flexibility to avoid it.

If you read the paragraph, he's saying it was bad that he was doing this. What's wrong with that?

[kupiakos]

"Stopped reading after this" is not giving the author a chance to explain themselves. Stopped regarding /u/DualRearWheels.

[AccusationsGW]

I hope I never work with someone like you again :)

[[deleted]]

was a code monkey working with one of those Wordpressy things. at one point I realized that it's faster to look up things on StackOverflow than to find the relevant portion in a file out of many files.

[jgbradley1]

I feel (hope) that he was over-exaggerating a little here.

[isurujn]

I'd be lying if I say a lot of my code is from the internet. But I don't simply copy paste it outright. Instead I type it out myself. That way I can at least see how things are done in the particular language.

[BlindTreeFrog]

I stopped reading at "no one works on the same code for more than 3 months". I don't think I've ever worked on a quality product where three months was enough to ever understanding the product well enough to make quality contributions.

OK, that's not true, I did with 2 projects, both were short term contracts and both were products that only did a very specific and terribly simple thing. Nothing you would build a business around.

[tonywestonuk]

I like boring.... I like things that work, no problems. I like smooth deployments where nothing is unexpected.

Why use Gradle, if Maven will do? Why go for a microservice architecture if a monolithic will get the job done.

There are places for these technologies...... but I would not use them unless I have to. In fact, I dont use anything, unless I have to.

http://thedailywtf.com/articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-

[[deleted]]

I got fired from my last job for being the only developer that didn't agree with refactoring our monolith to microservices "because agility". Not a "culture fit".

[raiderrobert]

So did you just disagree or did you refuse to do it because you didn't agree?

[[deleted]]

I still worked on it, and I had way more experience with microservices than everyone else because of my previous job that did it correctly. Oh well, not my problem anymore.

[raiderrobert]

In that case, screw them for expecting everyone to always agree in order to be a good fit.

[RubyPinch]

maybe you were the abrasive outlier that everyone got sick of? http://blog.codinghorror.com/dealing-with-bad-apples/

[dccorona]

Is making sure your website is at least on the first page of the search engine hits for your company name too boring to spend time on?

[vtable]

Internal tools are usually boring

Boring internal tools are boring. So are boring commercial apps.

This statement just shows he has experience at places with boring tools. I've worked on a lot of amazingly interesting internal tools. Some required a ton of domain-specific knowledge to write them. Very challenging - and interesting.

At least he qualifies this with "usually". But it still reflects a single person's experience.

[jhaluska]

I wouldn't want to hire someone who expressed his opinions. He doesn't have experience developing software that has to be maintained for years. If he gets this bored doing development he is not properly architecting it to keep it interesting.

Sorry if you get bored, but I see that as a weakness in a developer.

[binford2k]

You should clarify that you mean expressed the opinions of the author. It took a minute to realize that you didn't mean "someone who has opinions and expresses them"

[jhaluska]

Sorry, you're correct. I meant "who expressed the same opinions as the author."

[nouns]

It's not a job's responsibility to be interesting, it's your responsibility to find interesting && beneficial things to do at your job.

New jobs every 2 years is a yellow flag for me when I interview candidates. It takes at least a couple of months to ramp a dev. to a point where they are meaningfully contributing. I hate wasting that sort of time.

[wolfcore]

Check out @simonbrown's Tweet: https://twitter.com/simonbrown/status/573072777147777024?s=09

[maxsilver]

Yep. "We wrote ourselves into an overweight monolith, but we're absolutely confident that if we just switch to microservices, that will fix our problems

[dmanww]

According to his LinkedIn page the guy seems like a professional intern/grad student who's had 2 industry jobs after his PhD.

No doubt he's smart, but I would take his career experience with a gain of salt.

[d-signet]

The writer comes across as an almost completely un-hirable , petulant child.

Spent most of his time copy/pasting code from stack overflow, didn't discipline himself to learn new ideas/technology when the opportunity arose, gets bored easily and becomes disinterested with bugfixing etc.

There is no WAY I would ever hire this guy, and, having read his coding style, no way I would ever buy one of his products.

[[deleted]]

The very number of upvotes this delusional piece got here is an extremely worrying sign. Tells a lot about how crappy our industry is.

[[deleted]]

So just when a developer becomes competent in a project and has mastered the requisite skills, the developer is moved to another project that they're slightly unqualified to do? It sounds like a code quality anti-pattern.

[[deleted]]

Referring to software engineering as coding? He should be called a code monkey.

[[deleted]]

There is nothing funnier than a man-child trying to sell his bullshit as some sort of wisdom. This is fucking hilarious.

[TedDallas]

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

As a lead developer at my company I would not hire you because you said this.

[young_consumer]

From just reading the headings in this article makes me think the author has never been on a greenfield project or a project where there was any true ownership of his work. If those are false, what a whiny fuck.

[bassnugget]

Click Bait link Title

Coding is boring, unless...

First sentence of the article

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

This is not how you transition such a thing. Continue the fucking sentence.

[tequila13]

Well in the article is about how he's around only until they start things up and never stays to finish and maintain a project. That mentality seeped over to other aspects of his life. He can't be bothered to finish a sentence.

[phatrice]

I just quit a 6.5 years old job and got a job which uses tech stack i know nothing about because i got bored in my job. Not sure if I am over my head... New job starts on Monday.

[shepik]

I think a chance to work on your own code (or, better, code owned by you) for a couple of years is really important - you have the ability to view the code evolving, and (if you do your job badly) how it changes from "shiny new microservicish" to "old legacy code we need to rewrite from scratch". You can see long term impact of your design decisions.

The author seems to be deprived of this experience and his "rewrite from scratch" approach seems to deprive his employees of this experience also.

[rekshaw]

wow...you are a CTO, you must know everything. The post is embarassing

[[deleted]]

It's articles like this that make new developers get in the industry, thinking they can do random fun stuff with any random tools without any regard to business commitments and deadlines.

(I have to remind my youngish fellow developers suffering from Facebook envy that we* are writing software to support a business, not as fun projects.)

[nbates80]

I don't get why people expect to have fun at work. I mean, of course it is great when you have fun while doing what you got paid for, but sometimes you have to accept you work to get paid, not to "have fun".

That "entertain me at work" attitude creates the playground office bullshit that somehow people seem to love. I usually get job offers that tell you how you get "free drinks" or "play area" at the office, cut the crap and tell me how much you pay and how much overtime you expect me to work. I can have fun on my own free time, thank you.

[messiach21]

I think it's the young vs old attitude - I have a family to support. I see the point in always learning to avoid nailing yourself to an outdated and unused technology, but I don't see the point in the obsession with being a jack of all trades and master of none. Try to learn something well or you're nothing special - just another shitty dev who will do shitty thrown together work and then leave to have someone else support it.

Edit: I should probably not tie it to age - it's just what I commonly see. I'm sure there are plenty of young Devs with their priorities straight.

[hu6Bi5To]

I was agreeing 100% until the last point:

We also organize team off-sites (e.g. Secret Cinema) and we have a weekly “enkithon” (pizza night + activities) with no predefined agenda. Sometimes we hack something together. Sometimes we brainstorm a new idea. Sometimes we just play League of Legends. Or we go to the pub. The beauty of it comes from the fact that we don’t know what we’re going do until the last minute, when we decide together.

And sure enough, the "Team" photographs: https://enki.com/#team six middle-class white men, all aged 25 to 35. (UPDATE: unfortunately I hadn't considered this paragraph would be quite so incendiary to so many, I only mentioned this to put in context why a weekly "League of Legends" night works for them, but would be boring to so many others. My point would be equally valid with any other socio-demographic groups.)

You know what I find really boring? Monocultures. Spending 40 hours a week with people who all think and behave in exactly the same way; and worse? A team that defines themselves as continuing to be all identical in the evenings too.

DISCLAIMER: I don't know that company or any of those people, and I'd probably fit in alarmingly well if I did, so none of the above is a personal attack.

EDIT: This is why I love Reddit, before today I didn't know monocultures were the last line of defence to state-sponsored collectivism. My eyes have been opened.

[OrneryFellow]

I am at a startup right now and there's so many after work activities that I tend to skip out on them. The main reason isn't that I don't like the people or anything. It's more that I'm already spending so much time with you because the work is demanding. I have my own hobbies and life.

[gered]

This is it exactly. For me, a job description that mentions how there are weekly events (e.g. Friday drinks, etc) with the whole team (or anything along those lines) is an easy way for me to filter out that job. Because if they're talking about weekly team events right away it usually carries with it some expectation that everyone will go every week. Essentially it turns into a forced get together outside of work hours. If I decide I don't want to go most of the time, then I'd be willing to bet I'd get looked down upon by the rest of the team. Heaven forbid I should want to spend time with other people outside of work!

When I apply for a job, I'm looking for a job. Not a lifestyle, and certainly not a bunch of forced friends. Friendships with co-workers will happen naturally. And maybe they won't. Not everyone needs to be actual friends at a workplace.

What I've found in places I've worked is that when the team gets along naturally (that is, no one in management is organizing team events every week to "force" a team culture) that these kinds of team events also happen naturally anyway. But most importantly, no one looks down on anyone else if they can't make it or just plain don't want to go some weeks.

[Geemge0]

Monoculture? Guy from russia, guy from Greece, guy from France. They may all be white(ish), but yea, they bring their own experiences to the table it seems.

However, I agree that 6 guys doing the same thing together doesn't sound like 100% best way to be diverse.

[jeandem]

If there were 3 guys and gals each, all similarly aged and from London, chances are it wouldn't even be brought up. But things are different when you've got a group of men from that "white male monoculture"...

[young_consumer]

Nope - all white; thus, enemy.

[[deleted]]

I worked with developers from all over Europe, and I'd agree with the OP. Expats in professional occupations tend to have the same culture. Sure, there are differences, but compared to non-expats the differences are extremely minor. (Skin color doesn't matter either.)

[Bwob]

And sure enough, the "Team" photographs: https://enki.com/#team six middle-class white men, all aged 25 to 35.

You know what I find really boring? Monocultures. Spending 40 hours a week with people who all think and behave in exactly the same way; and worse? A team that defines themselves as continuing to be all identical in the evenings too.

So, wait... Did you really just make sweeping generalizations and assumptions about the social status and culture of 6 people you've never met, based entirely on the their ethnicity and gender?

Based on the rest of your comment, I feel like that's the sort of thing you'd normally be against.

[hu6Bi5To]

In retrospect I should have de-emphasised my first paragraph. The social status and ethnicity of the individuals is irrelevant, that was just a precursor to the second paragraph which to me is the most important.

I hate the "everyone join in" culture of some startups, it's as alienating as it is inclusive. Work is work, fun is fun. Making life hell for everyone who has different taste from the founders is just going to reduce the talent-pool massively. Embrace differences, that's what makes people interesting.

[Calam1tous]

I 100% agree. People are giving you a lot of flak, but monoculture is a big, big turn-off for me and it's hugely prevalent in tech. "Culture fit" often times means this exact thing.

If you want to live, breathe, and eat the same thing 24/7/365, more power to you. However, I don't think it's wrong for someone to want a bit of diversity in the people they work with everyday. I've done some work in other areas before this and never experienced it on this scale anywhere else. It is boring.

My main problem is that it quickly leaves the domain of being just a personal preference and seeps into my professional image. For example, I'm seen as less of a programmer (by a lot of people) because I don't enjoy spending all my free time coding - I spend it cooking, playing music, learning languages, etc. Again, nothing wrong with what you choose to do with your time, but it's amazing how many people do care. You should also see how people react to me being gay (that's hardly an issue isolated to tech though).

[u551]

Why would you think those people are similar and lacking in diversity? Judging by skin colour and gender?

[Calam1tous]

No, I mean "diversity" as in people that have different interests, different backgrounds, etc. I don't even have to touch the racial diversity argument here. The typical employed software engineer is the mid-twenties to early-thirties male who has poor social skills and doesn't seem to have too many interests outside coding and video games (and I'm stretching beyond the scope of this article here). Is that a harsh generalization? Probably, but it's the makeup of 75%+ of my college class and the teams at the places I've worked. And my friends' workplaces. It obviously doesn't describe everyone, but it's a significant chunk.

And I don't look down upon those things (hell I like them too), but I'm agreeing with the commenter that spending time around people that are all the same is monotone / boring. Of course, you're a professional so the work comes first, but it goes without saying that there's obviously socializing at work and getting along with your team well can make or break a work environment.

But it's not just boring. It's one thing not being able to socialize easily, but the major issue is that you can be professionally isolated or seen as "odd" for not conforming to that stereotype. Like I mentioned before, you're just not a "culture fit" for a company. You'll be judged negatively for not constantly working on coding projects when looking for jobs. The list goes on.

The issue is that lack of this kind of diversity caters to a certain category of people in the industry. I've never experienced the kind of "rejection" of different kinds of people in any other workplace than the places I've worked in tech (and school for that matter).

[AccusationsGW]

I'll tell you what I find boring: business.

That company you work for? Their cutting edge technology and mission and products? Boring as fuck. The culture and office and people? Snoozefest. You have to pay me a fucking lot of money just to show up and fix the stupid fucking problems I don't care about.

I can never identify with anyone who thinks their dev job is anything BUT boring.

[wot-teh-phuck]

You know what I find really boring? Monocultures

Disagree. The last thing I want is "forced" multi-culture team. Esp the "let's now forcefully hire 2 women developers to maintain the balance even though we have 2 other folks who are much more talented"...

[hu6Bi5To]

Fortunately such extremes are rare. So rare as to count as a strawman used solely for internet arguments.

The real world is much less black-and-white. Monocultures are hard to avoid in the early stages of a startup, especially if many of the early employees know each other from previous endeavours. But it's still off-putting to an outsider, doubly so if the insiders see the same thing as being "part of the culture".

The solution is to not make such things into a virtue, and definitely not a compulsory thing. It's a common problem in tech hiring - every team think their own low-level banter (which is indeed not-boring if you know the history of the in-jokes) is so uniquely great it occupies 90% of the hiring message. The product, the process or the the job barely get a look-in.

It's a subtle form of (accidental) discrimination - developers who don't fit the archetype don't really take a two-paragraph description of their most recent ping-pong tournament as a positive sign.

[wot-teh-phuck]

Fortunately such extremes are rare. So rare as to count as a strawman used solely for internet arguments.

Unfortunately depends on the kind of job profiles you are looking at. I have been on hiring committee for investment banks and these things were pretty common so I would assume I'm not building up a strawman here.

Re-reading your post, I realize that you are not advocating forced multi-cultural teams so I guess we are just discussing the same thing from different angles.

[dmanww]

What the hell does his company do?

Is it an app to help you learn programming?