Coding is boring, unless
blog.enki.com
blog.enki.com
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 ...
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.
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.
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).
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.
I don't think it's that they get outdated. It's that they each try to solve the hardest problem of web UI programming: keeping track of state and binding data in an asynchronous world. Unfortunately, each one ends up with pain points in different places.
Each successive framework tries to solve the new pain points by rethinking the original problem, because reworking the original framework to ease that pain point would often require massive restructuring of apps built on that original framework - the issues are often architectural.
Angular, for example, is fantastic for getting a very simple CRUD app up and working. But try to do anything fancier and things get very hairy very quickly with a web of controllers, directives, scopes, etc. Getting into a place where one data change cascades and kills your app is a very real concern. That's the pain point React/Flux attempts to solve. Angular can't solve it without some major architectural changes - see the hubbub about Angular2.
We're still in the baby stage, I feel - while each successive framework may seem faddish, they don't really get outdated. Out of favor for new projects, perhaps, because the developers who used the older framework were so frustrated with the previous tool's rough edges. Things will probably settle down soon (especially with the fantastic language improvements in ES2015) :)
But everyone else in the world thinks it's sane to write applications inside a thing meant for displaying documents...
As a result of its effects on the work of other members of the team, such people often have a negative net productivity. I, too, am in favor of making things interesting where possible, but not to the point of indulging the Dunning-Kruger effect.
Could you imagine if everytime you wanted your HVAC upgraded, your contractor decides to rip out your entire current system and replace it with something new ("this new polymer ducting is awesome!") just to keep their engineers happy?
There's a time and a place for all types of projects, and the mark of a successful engineering effort is to have engaged engineers regardless of the 'cool factor' of their work.
In fact, this whole thing stinks of poor leadership (not just management) and undisciplined engineers.
-- snippet from a more or less realistic set of requirements for a "2 years of business logic" app. I do not want to be here in another 28 years...
If you chose any of the major frameworks for your application you'll be good. Django, Rails, Java EE, Spring, Play Framework, Meteor. These aren't likely to go away anytime soon, and they've been around for a while.
On the front end it's a much more dangerous approach. If you have one or two pages that use the latest flavor of the month, Backbone(2011) Knockout(2012), Angular(2013), React(2015), you'll be ok.
The problem comes when you just re write your entire front end app in one of these. I like to experiment with front end technologies on one page, but I would never buy into the SPA for the entire app. The shelf life is way to small. They'll still be supported probably.
If your trying to keep or hire developers, putting backbone.js as a tech you use probably won't get as many applicants as say React.js. Since most front end devs right now are trying to introduce React into current job or jump to a job where they use it.
Even if you said yes, you're only kicking the problem down the field a bit, because six months later they'll get just get bored of the new stuff they've rewritten and will want to move on to rewriting something else. Ad infinitum.
I consider these people the "90% engineers", meaning they like to take a project from 0% to 90% complete, but then once the going gets tough, and they're no longer writing new code but trying to track down the bugs in their existing code, they decide it's no longer fun and need to move on to something else.
These people usually fail to realize the implicit risks associated with throwing away an existing codebase and starting over from scratch. All that time spent ensuring the business logic is correct and tracking down obscure bugs will need to be repeated in their new rewrite. (Spolsky elaborates: http://www.joelonsoftware.com/articles/fog0000000069.html)
These people are essentially spinning their (or rather, their company's) wheels by creating more work for themselves, without actually getting anything done.
That doesn't mean always choosing new & interesting, it just means that when the business CBA gives only a slight preference for old & boring, you instead err on the side of new & interesting. This is just advice "on the margins". When the boring tech is clearly much better than the interesting tech, you still stick with the former.
If you agree with those two assumptions, then the guess it is a good value proposition he proposes.
When you're learning a new language you usually end up with unidiomatic code, and can't use the language tools effectively yet. The most "exciting" languages may not even have a stable tool set.
They seem to me that they have this wanderlust to switch jobs and try something new every couple year and get a kick out of it. I don't think that there's much to do to retain them and make them feel excited all the time.
Chuck 'em. Nobody needs that type of developer.
Even if not, they may not be paying attention to things that matter to your business, and may ultimately do more harm by staying.
Or it's the only reasonable way to get a decent raise. Staying at one job for too long can end up losing you a lot of money in the long term, unfortunately (and make it harder to get a new one when you decide to go looking).
The problem is when those developers _only_ want to work on shiny. Developers need to understand that they need to work on maintenance projects as well.
As a CTO/manager/team lead, your objective is to mitigate things; keep things interesting enough while getting things done.
This usually means avoiding over-engineering, leaving some room for the team to pick the tools/technology they want (as long as they understand they will assume its maintenance) and making progress visible (celebrating milestones, having regular stand-ups...).
And even then, people will leave (some programmers can't get the remaining 20% done), shitty code will creep in and have to be maintained, and you will occasionally have to deal with legacy stacks. And that's fine.
If you call it quits because you don't want to get your hands dirty, I'm not sure I want you on my team.
So eventually I specialized in one of those areas and got promoted myself during the 2nd half, so much so that Google poached me (that didn't end well, but that's another story). These days, I work amongst the full-stack crowd who want everything written in Python so they can modify supposedly low-level inner loops with impunity. When repeatedly confronted with a C or GPU procedure that is 50-100x faster than its Python equivalent (dynamic typing in inner loops is a harsh mistress and even numpy can make Python coders do really strange things leaving one with code still 5-10x slower than bespoke C/GPU code), they complain about the difficulty of writing C/GPU code rather than consider the performance they're leaving on the table and the money they're wasting by running performance-sensitive code that way.
But then, I've always considered getting my hands dirty and rooting out bizarro bugs the fun part. The hardest part for me is when to say a project is done because I can always find room for improvement. And I prefer to work with people who have a similar viewpoint. It's not easy to find them.
I was wondering why I keep seeing this everyone. Python this, Python that.
By realizing that you'll make even bigger of a mess the next time around?
https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sec...
[1] If it were self-documenting, or even just documented, I would probably not be thinking of fixing it.
And if you're going to the trouble to understand it and wrap tests around it, then maybe refactoring the existing codebase is a smarter choice. If less sexy.
I think a good mindset to have is to look for the challenge in making decent refactorings.
I wouldn't say that is necessarily true, given the solutions he proposes. While I do think the article is laden with naïveté, his proposed solutions at least seem to factor in the reality that costly rewrites are a problem. He's finding ways to minimize that cost.
Software is created, knowledgeable developers get bored if you don't take their needs into account, they quit, software dies, sometimes slowly enough for the business to not even notice, sometimes fast enough for business to die too.
I don't see how ignoring the problem, of developing software not being fun, does anything but harm the business.
The cost of managing microservices and whether multilingual environment pays off is a separate question. Rewriting a now much better understood solution using an appropriate technology could have dramatic effect.
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.
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.
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?
If you think about it, most of the code we benefit from each day was written by someone else from the operating system, to the language compiler/interpreter, to the frameworks, libraries, etc.
Many developers get their queues about how to use a language, framework, library, or application because they learned how to use it on StackOverflow.
Do you really know how much code was written to get to the point where you are sitting there, using all of the benefits of past coding, much of it thrown away to make way for other code for better or worse? All of that code is likely far beyond 50% of what your company has written.
So now when I hear claims like this, I just assume it's coming from someone that is new enough to a specific technology that relying on SO is necessary for them.
SO is amazing when it has information that I'm looking for. You know why? I don't want to have to figure out literally everything. I want to save my figuring energy for tasks worth applying it to.
So just get the fuckin' job done and do it right and quit pretending you're trying to achieve nirvana.
But I feel the first step should be going to the documentation of whatever language or library you're using, rather than Stack Overflow. SO will tell you the answer to a single question, the docs usually give some more information (you don't get "use this option", but "here are the options and this is what they do") so the chance is higher that next time, you'll just know the answer.
Of course when inexplicable things happen or when docs are bad, SO can be pure gold.
SO is a unique combination of framework docs and practical examples. Inevitably you'll find sample usages of the framework or domain knowledge, applied to a problem similar to the one you have and can apply easily using the "skill" or craft of programming.
Other than that, it's pretty much CRUD and algorithms that a developer has to do. And the latter of those is sadly not needed for most development work out there.
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.
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.
Source: did too much webdev in my life already, and wasted way too much time doing things by myself.
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.
Good for you that you ended up in one of those positions, though. Probably enjoy your job more. :)
I've personally never seen anything that can be described as "regurgitating the same CRUD for different customers" in my career as a webdev and certainly not 90%. There is of course wiring standard components together but that's surface level stuff, the guts are not standard components.
That's just my experiences for what it's worth.
And, yes, I'm very blessed to enjoy my job and believe me I don't take that for granted.
Going back in the thread I honestly don't think that reaching for Google and SO as your first impulse will deteriorate your ability to find your own solutions in the long run. Not by itself anyways. If the problem is standard then those are not problems you should be implementing your own solutions for anyways and Google/SO are great for finding answers to standard problems. Copy-pasta is great for syntax and boilerplate code.
If the problem is not standard I learn from Google, I don't just copy-pasta, I look at how other people have solved similar problems and use that as a basis of creating a new solution.
I can see how people who don't want (or can't) think for themselves can fall into the copy-pasta whatever they happen find without truly understanding. In that case Google/SO isn't the problem - it just makes the problem more visible. These people will never be good engineers.
Whereas I hadn't heard of the problem in the Valley as they're always riding one wave or fad after another. The people that report the issues I described are almost exclusively outside the Valley or startup scene mostly working for mid-sized to large companies without much IT innovation. Reading comments on many programming and job sites makes me think they're the majority (or just vocal majority).
Might be different in your area or the types of companies you work for. Most I know in banking, retail, logistics, manufacturing, hospitality, and services firms... a huge chunk of job market... do CRUD style apps and have lots of legacy systems they expand on rather than replace. Lots of boring work.
Does vary by industry, area, and technology stack, though. Interesting to see yours is mostly interesting, custom code instead of throw-together apps many get stuck with. Honestly, though, I think the SO use is less about CRUD than the information overload of various libraries and frameworks where people constantly run into issues due to lack of understanding/experience.
No pain, no gain.
To be fair, sometimes I try to solve problems for an hour or so before going to the Google or SO, and when I find I derived roughly the same approach, I consider it a done-deal that it's probably the right way to solve the problem at hand.
I would love to see a coding interview where the interviewee has access to Google/SO. It's a far more realistic portrayal of their on the job capabilities IMO. It would also force interviewers to come up with more interesting questions.
I don't understand why anyone wouldn't start with that. Pride?
You're the manager. The engineers on your team have 20 or so tasks to do, rote, boring stuff, such as "serialize object X to JSON" and "send serialized stream to server Y". Would you rather your team 1. take a day or so to "work real hard" re-implementing JSON serialization, or 2. just copy/paste something already working, spend an hour or so adapting it to the project, then move on to the next task?
Or by how most family lawyers do 90% of their work by entering names, etc. into a Word template that was written years ago. Getting my will written was an eye-opening experience: I told my lawyer who I wanted my property going to, who I want it going to if my first choice predeceased me, and who I didn't want my property going to, and he just typed a bunch of names into his template, hit "print", and called a couple of witnesses and a notary into the room so we could all sign it. My living will was even simpler: I told him I wanted one, so he just typed my name into his template and had it printed and signed just like my regular will.
From the customer's perspective, what matters is that their problem gets solved, not how it gets solved.
Yes, because the reality is that someone has to do it, and a half-assed effort from a developer browsing SO is still better than getting a random Joe off of the street for $10/hr to try it.
Not all companies have interesting problems to solve 100% of the time. It's not impossible that your company is trying to solve a problem that the majority of SO questions will answer, because your problem is just that boring.
If that blows your mind, you should know there are people that get paid well to do stuff that is a lot more simple than even cobbling scripts together from the internet.
Bootstrapping up from hello world is nearly guaranteed to work, write the entire thing first then try it is a recipe for pain.
In particular, people copy-paste a lot of JS from SO, and again, it's no surprise. Most of the web development isn't done by superstar sexy rocketship startups on the bleeding edge of Node.js ecosystem - it's done by small companies employing barely competent programmers, and it doesn't require any innovation. It's just taking the same components everybody uses, configuring them in the same way everyone configures, and wiring them together in the same way everyone does.
Repeated again in past 10 years with OOP, SOA, micro-services, and so on. Applies to configurations and admin scripts, too, not just code.
Pretty much everything I do requires parts that came from SO, but it's more like I get a bunch of puzzle pieces and then think about a smart way to assemble the big picture.
Then there's the profiling and arrangement that only makes sense on my particular codebase. No way to SO that.
Have you been on SO?
Now you have beginners asking so simple questions it's both funny and tragic at the same time.
Here's the first question in the list when I opened the site today:
http://stackoverflow.com/questions/33989450/mysql-joins-on-t...
Yeah. That guy is one of those who just ask others how to to their job and then copy/paste it.
Who answers such questions? I have no idea. Probably the guys who are just a step above on the knowledge curve. They probably hang around to ask their own questions, and also find such questions challenging enough to bother providing an answer.
As for the question, you obviously didn't read what I wrote carefully. I get served a full page of such questions every time I open the site. Finding an interesting question has became a tedious job and that's why I don't even bother to visit the site anymore.
Once again, I'm not even sorry about that. It freed a lot of my time - I rarely visit the site, but I'm still ranked in top 2% users, so you can guess how active I was before.
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.
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.)
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.
Yes I know you can get docks etc for laptops but its far more expensive for the same performance.
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.
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.
My first real office (after a couple months working out of my living room) was a shoebox. I was mostly meeting with clients but when I was around I didn't even have a desk. I had a chair... by the door.
I'm usually shocked by how well equipped startups office are for teams of less than 10 in SV.
Suggested office square footages: http://www.officespacefinder.co.uk/officespacehow.html - does this place look like they've got even 50 ft^2 per person?! Packing your staff in like battery hens or galley slaves is unhealthy. Those poor people in the photo (assuming it is their office - the question has yet to be answered conclusively) are suffering from terrible ergonomics and cramped working areas, both physical and virtual.
So what if you're this scrappy startup - that sort of thing is a false economy. Your staff are pretty much your only asset.
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.
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.
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 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
What you build is the issue. Everything else rest are details.
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.
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...
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.
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.
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.
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.
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.
Figures are quoted to me by a PM who oversees some devs in a well known Swiss bank in Canary Wharf.
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.
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.
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.
To contrast, here is Rich Hickey on Mastery: (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.
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?
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.
I believe every project has it's boring parts. But when the goal is positive it helps to get thrue.
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.
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.
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.
Ditto here.
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.