> You can rewrite it from scratch, using a different language or technology. This way, you learn something new rather than patching legacy code. And if your architecture doesn’t allow this yet, you can take steps to improve it, and learn some devops skills in the process.
In a professional environment, we develop software not because it's fun, but because it supports the business and/or because it is the business. The primary purpose is to make money and to pay our salary. Now, that doesn't mean that coding can't be exciting or that you're not supposed to have fun. Not at all. But I feel that the author largely fails to see the business perspective. Rewriting things from scratch, adding another language to the overall architecture, using some fancy new technology, etc. are not wise business decisions in /most/ cases. Especially the comment about "using a different language or technology" will lead to a maintenance nightmare in the future ...
Most engineers take years to internalize this concept. Fresh out of school programmers will throw themselves at tough problems, get 80% of it done using the latest popular framework before they want to move on. The problem is, the remaining 20% is often what will drive success or failure.
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.
I spun my wheels for the first half of my stint at a tech company by being the sort of full-stack developer who never really specialized in anything. During that time, I frequently noted that the engineers who were promoted to the top were specialists in one or more areas important to that company's goals. My managers always told me I was mistaken about that.
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.
Its very much the case that new engineers want to work on the hardest projects and prove that they are capable and deserve lots of money and/or responsibility. But management typically doesn't care if you completed 99% of the hardest project on the block if it doesn't yield a usable result (nor should they). Its generally better to solve a simpler problem well enough to at least claim success. The downside is that if everyone feels that way, the quality of the framework for future tasks is not robust and technical debt racks up. Without a sound framework, there isn't reliable infrastructure and navigating previously written tools can't be trusted by glancing at a method or package name. It turns a depth 1 BFS into an unbounded DFS and eventually it becomes extremely time consuming to get anything done. The problem gets compounded if there is a lengthy review process and the reviewer is safer doing nothing, letting the change languish until a manager pushes for it.
Here's how I would interpret things. Each method ("old & boring", "new & interesting") has costs and benefit for the company, and cost and benefits for the developer. The naive way to make a decision on which tech to use is to do a CBA for just the company, but this essentially incurs hidden costs for the developers (boredom) which eventually is inflicted on the company (quitting). So make your best effort to estimate those hidden costs and factor them into your decisions.
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.
I am bemused simply by the author's idea that rewrites are interesting. It is probably a good sign if a developer is irritated by cruft in existing code, but to feel compelled to redo the whole thing 'properly' strikes me as borderline OCD (full disclosure: it happens to me occasionally, but I quickly get over it.)
I usually find it's a sign of a developer who's too lazy to understand the current code, but arrogant enough to think they can make it better by starting again.
Yip, you can't really do a re-write unless you've gone to the bother of understanding what is there in the first place (and wrapping tests around it, if at all possible).
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.
That is probably the rational assumption for me to make, but I'm not that much more self-effacing than the average programmer. What usually does the job is contemplating the amount of work it would take to divine the current implementation's requirements[1] and the amount of testing that it would take to show that I had correctly implemented them. That is when I realize I can live with the existing implementation and that I have other things I would rather be doing.
[1] If it were self-documenting, or even just documented, I would probably not be thinking of fixing it.
I've seen these types of projects where a few developers just went overboard with all the new frameworks and languages. Two years or so later most of them have moved on and other devs are stuck with technologies that are now considered outdated. Especially in the JS world, that's a real scenario.
I am all for keeping your engineers happy. Heck I am one of them. "Exciting" can mean "better architecture" or "extensible", but I think that adding a new language is always a bad idea.
> Isn't that a case of not letting developers rewrite anything? How did it got so outdated?
If you're writing (or rewriting) using whatever's hip/new there's a good chance it will be "outdated" within a few years. New languages and frameworks come out all the time and nobody is able to determine with certainty which have real staying power - but something that has been in [wide] use for 10+ years is much more likely to still be widely used ten years from now than something that just came out last year.
Think of it like music, people have been listening to Mozart for centuries - it's highly likely a hundred years from now people will still enjoy his music. It's a lot less likely they'll be listening to Taylor Swift (nothing against her / her music - just using her as an example of someone who's very popular right now).
There's also a chance writing your project on that 10+ years old platform will cost you enough time/money to write it three times in a more modern one.
Well, you sound like somebody who I'd agree with most actual decisions about this. But I do disagree with the overall position. Holding down too much at "it works, don't change" has actually worse consequences than adopting immature frameworks all the time. That's not exactly like music - software tools do get old.
Good platforms, of whatever age normally last for a long time and should be safe. But if for some chance one didn't last, one shouldn't be too resistant to replacing it (piecewise and slowly), because the cost of not doing that is just too big.
> Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong.
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) :)
Got a better solution, with wide adoption, that can get you on just about every internet-enabled consumer-facing computer in the world with the same codebase? :)
Indeed, and it is not just with frameworks and languages, but also architectural and methodology fads. Several times, I have seen those who see themselves as architects try to roll their own frameworks or even languages within a project (the 'inner platform' phenomenon, which is quite common.) Those I have seen have all been failures, once catastrophically so.
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.
Ha. I mean, every engineer loves a green field project, and everyone wants to do a technically sweet project. But engineers of all people should understand that not every project can be technically sweet, and certainly not every project can be greenfield.
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.
Engineers always under estimate the amount of business logic in an existing application. This is one reason my mainframe apps are so hard to replace, they often have 30 years of business logic built into them.
I agree with you on principle, but I've always wanted to see one of these "30 years of business logic" apps up close. What's most of that business logic? I can't imagine all of it being essential and at the minimum possible complexity.
"Normally, component A completes then sends a message to B, who blocks while a file operation occurs, and then sends a confirmation to C which updates the UI. When configuration option D is enabled, B must make the write twice because of X, which requires component E to act as a delegate to intercept the normal message from B to C so that this can occur without changing the implementation of C, since it has been externalised and is used in six other projects. Also, file writes are disabled on weekends, except the fourth weekend in February, unless this weekend doesn't occur."
-- 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...
In the backend, a new language for a new service would likely be ok, if it's pretty small.
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.
If an engineer gets bored and leaves because they wanted to rewrite your codebase and you said no, that's probably not an engineer you wanted to retain anyway.
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.
Aren't these vagabond workers destined to leave anyway?
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.
I'm sure there are some who just like changing jobs. But most of the programmers I've known have moved when they could get more money or thought they'd have more fun at the new job. If you're paying well and keeping the fun factor above average, fewer of them will move, since there's a high risk that the new job won't be as good.
I agree but I was just pointing out that it's almost inevitable for some developers to leave the organization for reasons beyond the control of people running the org and therefore it is not worth it to have the org undergo a cultural transformation and turn it into a fraternity just to dissuade them from leaving.
They can often be the ones who love their craft, enjoying evaluating new approaches, spend their own time coding and learning the latest frameworks, and can be the best coders on the team, able to tackle the more difficult problems with the best solutions.
But also refuse to maintain either the software they wrote or the older version that is still bringing in money while the new version is being written.
You can start by not inventing insulting nicknames. If you are in an at-will relationship you risk the other part leaving at any time, and you really shouldn't complain about it.
> try something new every couple year and get a kick out of it
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).
Even if you accept that, the cure may be worse than the disease. You'll lose programmers in under 2 years if they have to maintain a mishmash of learn-as-you-go style code with multiple quirky build and deploy systems, which seems to be a common result of the "write it in a new language" attitude.
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.
quite. It seems to be the curse of the era that the techies are constantly chasing the "shiny". It seems that the web, through the likes of PHP and JS, has turned "programming" into a form of self expression. That the language used etc is supposed to say something about the programmer as a person.
Because developers are usually "let go" before management or sales, they have to keep their skills up to date in order to get their next gig. That's where the shiny comes in. Shiny gets hired. Dull doesn't.
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.
> 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.
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 quote is missing important context. Just want to clarify that author is speaking about microservices specifically. The whole point of microservices is that one could be rewritten in a matter of days without involving substantial risks and expenses.
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.
> But I feel that the author largely fails to see the business perspective.
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.
I think you're taking that quote out of context. Right before that, the author indicates that he's talking about micro-services, so ideally a complete from-scratch rewrite of a single component wouldn't actually be a very big project.
I've been programming professionally for 15 years. But I cannot say that I was ever bored programming.
My favorite story about this comes from my first job, in 2000. We were working in C++, and we were turning a program designed to run in one machine into a client-server system, because nobody made machines big enough to run what we needed. The plan to do that involved replacing the old function calls with code that serialized the data, sent it over a wire, deserialized it on the other side, and call the actual function. In essence, a small bit of smart code, surrounded by a lot of boilerplate, slightly different for each function. Months of boredom looming for a team of 5.
But I said: Why do all that serialization and deserialization manually? What If I can just read the headers for the function calls, and generate the code that would run it all? Way too hard, our dev lead said: It'll take us longer to write a code generator that read C++ header files than the months of boredom. I disagreed, and asked for two weeks of my time to show it could be done, with less bugs than if we did it by hand. And then when functions changed, all that we needed to do was add a step to a make file, to regenerate the whole thing. Ultimately he decided it was OK to let me try. After all, nobody expected any real output from the guy right out of school, and failure might teach him to respect his elders.
But it was all done in two weeks, by one person right out of school, because building a lexical analyzer,a parser, and a simple generator is easy. Instead of a team bored for months, we had fun work for two weeks, and then on to better things, without that dev lead.
So if you are doing something long, and slow, and boring, always wonder: Is there a way to just eliminate that entire set of boring tasks? You'll be surprised by how often, the answer is yes.
When you can afford it in terms of budget and timeline, I am a big fan of that sort of "race to the finish" between an elegant approach and a brute force one.
This is missing my biggest trick: one of my biggest ways of fighting boredom with code is focusing on meaning. E.g., if I'm building a system to serve particular people, I meet them, I visit their offices, I watch them work. I also like watching user tests and taking support calls. Even when some particular block of code isn't technically fancy, I'm not bored by it as long as it's of use to people.
Of course, once you start doing this, you're not really a "coder" any more, you're somebody who uses code to solve problems for people. This doesn't fit neatly into some managers' pigeonholes, but I think it results in much better products, so I'm ok with that.
Yes, so much this... I like new fancy stuff as much as the next guy but I'd describe my motivations as 'solving other peoples problems with technology'. That can be done just as easily in a legacy codebase as in a greenfield project.
> Because 50% of my code (hyperbole intended!) was a direct copy/paste of Stack Overflow. And another 40% was a copy/paste from other scripts. Either my colleagues’ scripts or my own. It became repetitive. And there was little creativity or learning involved.
How is this even possible? I've never had a job where copying and pasting code would have helped. It blows my mind every time I read this kind of claim, to the point that I sort of refuse to believe it's true. Are there people who get paid to do things that simple that they can be copied and pasted from Stack Overflow?
I would not be surprised to learn that a codebase is 20-50% made of stuff literally copied from SO (with occasional variable name change). Why? Because most work is not that unique. Rare are the jobs where you're building something new in software; usually it's solving slight variations of the same business problem.
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.
This was true way back when people were trying frame-based programming, 4GL's, etc. The same general components could often get the job done. So, the tools made that easy to express along with code generators to turn them into 3GL code (eg C, COBOL) specialized for the task. Both vendors and businesses developed an assortment of reusable components that became a selling point in time saving.
Repeated again in past 10 years with OOP, SOA, micro-services, and so on. Applies to configurations and admin scripts, too, not just code.
It always amazes me that there are people out there willing to hire and pay full these type of workers who scour SO for answers without working hard on the problem and expanding their knowledge and expertise in the process.
No wonder that our field and profession is suffering from bad image and quality problem when so-called pros copy and paste all the time on the job.
I think there are two ways to view what the job most programmers do is. IMO it isn't to write code, it's to solve business problems. Code just happens to be the tool that you use to do that, most of the time.
Anyone who tries to solve a problem by staring hard at a blank piece of paper instead of just googling the answer is not making effective use of their time.
Exactly, and most business problems are not all that unique. User input from form X goes to storage Y, output in report Z. There, I bet I've described, in a very high level summary, at least 50% of programming projects out there in one sentence. SO is a valuable resource because all these wheels need to get re-invented over and over everywhere. Unless you're lucky enough to be working on an inventive project at an inventive company, programming tends to be like plumbing: run this pipe from the source here, through that wall, to the sink there.
You are missing the forest for the trees. Reaching for Google and SO as your first impulse when confronted with a problem will deteriorate your ability to find your own solutions in the long run. Use it or lose it, as they say. And besides, any non-trivial problem can't be solved by copying code from SO alone.
Most companies don't solve non-trivial problems. For instance, 90% of web development is regurgitating the same CRUD for different customers. Most of the work consists of wiring standard components together in a standard way, and slapping some CSS on top of it. If you're trying to think too much and reinvent too much, you'll waste a lot of time.
Source: did too much webdev in my life already, and wasted way too much time doing things by myself.
> For instance, 90% of web development is regurgitating the same CRUD for different customers.
Maybe on the face of it, it looks like this to you but in reality it's bit complicated esp if you're aiming for more differentiation from your competition but if you're looking for just cookie-cutter, run-of-the-mill, copycat solutions, then all the products on the market definitely look the same.
You are both right. 90% of the websites on the Internet do look the same. You only have 10% (probably even less) products that are special and noteworthy.
I do webdev and I solve real and unique business problems. The web is just a convenient frontend for our users. Our backend has complicated data processing and solves unique problems. I know you said most and not all but just giving a counter example.
It's not really a counter example because TeMPOraL's claim applied to the majority. Following the resulting advice of using whatever gets the job done quickly (eg copy/paste) will pay off for the vast majority of developers in that space. Your example is a red herring here as the comment just wasn't about the minority doing original stuff.
Good for you that you ended up in one of those positions, though. Probably enjoy your job more. :)
I don't think its the majority outside of Silicon Valley though. I am very far removed from the Valley so the examples given look nothing like I've personally seen anywhere but I can see how that can be the case in the Valley from what I hear/see in the "news."
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.
"I don't think its the majority outside of Silicon Valley though. I am very far removed from the Valley so the examples given look nothing like I've personally seen anywhere but I can see how that can be the case in the Valley from what I hear/see in the "news.""
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.
Grabbing quick and easy answers from the Google and SO leaves me more time for the really interesting problems in my experience so far. And it's the really interesting problems that make writing bespoke C/GPU kernels worth the time involved in their creation so double-good, no?
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.
Disagree. My time is valuable, and I already have enough difficult problems to solve that I'm not interested in creating extra work for myself. If a quick 2-second Google/StackOverflow search reveals the solution to my problem, I'll happily take it and move on.
I don't understand why anyone wouldn't start with that. Pride?
It depends on the problems you're solving - SO does not help with problems of architecture. For code structuring, staring hard at a sheet of paper or nothingness can absolutely be more effective.
Can't argue with that. Although I do think architecture is where patterns start to be useful - again, relying on pre-existing solutions rather than creating your own.
Of course, but anyone who tries to solve a problem by copying the first piece of code they find on SO without even trying to understand the problem is likely to be similarly ineffective in the long term.
Technical workers solve technical problems not business problems. Upper management folks instead solve business problems. Our job as techies is to model/define the business problem in technical terms and then work on it. That's why they pay us and if some are not competent or proficient enough with their tech tools, that will reflect poorly on the quality of their finished product and copying and pasting won't always save the day for them. Also and this is very important, if they would like to grow professionally, they ought to work on their own and develop their skills organically or fear that they'll be stuck forever in the "apprentice" level for their whole career.
You would probably be horrified to find out that doctors diagnose most common illnesses by looking symptoms up in their med school textbooks. The more tech-savvy doctors now use WebMD.
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.
Why? Do you get more sales or market share if your engineers are sitting there working hard on inventing wheels that are one Google search away?
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?
When the deadline is tight and you don't have to debug the bluetooth stack to see why it doesn't work on Samsung XYZ on Android ABC, then SO is a godsend.
For the first year or so of learning Ruby and Rails, I did end up copying and pasting alot from SO. In fact, I think I had a streak of visiting SO every day for at least a year, and that wasn't idle browsing, that was "Oh shit I'm stuck, better hit up SO".
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.
I rarely visited SO for answers and I went through the novice phase like everyone else but I didn't pick the path of least resistance every time I'm faced with a technical problem, because I have a held belief that you can't accumulate knowledge and expertise if you don't polish your debugging/troubleshooting skills and make yourself go through the painful process of solving technical problems on your own without the help of someone else and I could say that help very much in honing my skills.
This thread is killing me. I have worked on a whole bunch of shit that has little to no documentation (SO included) in my career. I have had to figure out a lot of stuff on my own.
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.
If you write a paper you also first cite what is state of the art. Before you go into details what Innovation you came up with. So researching SO first, before reinventing the Wheel. Resembles more the scientific way of problem solving. You can also learn a lot by reading and understanding all the different solutions that are often given to a Problem. Your time is better used if you solve new problems or find a better solutions than reinventing the wheel and you also learn as much if not more.
It's hard to argue much about this because nobody so far said what kind of problem we're trying to solve.
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.
You of course don't want to go to SO for the "skill" of programming, you probably already know to do that as that is your craft. You go to SO for domain knowledge that you don't want to spend time scouring documentation for.
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.
>Are there people who get paid to do things that simple that they can be copied and pasted from Stack Overflow?
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.
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.
It's a platform for learning. The asker is a beginner. There is nothing wrong with that and someone asking with the intention of learning should never be looked down upon. If you find it so easy why are you even looking at that question? Your google-fu is sub-optimal?
I'm not looking down on anything or anyone. I'm just analyzing the state of SO today versus the first few years when it started.
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.
Fair enough. I find it a godsend. Nothing wrong with copy paste if it brings you forward faster and you take time to understand why it works. For architecture etc it's pretty useless but for the rest it is a very helpful tool.
Something no other commenters mentioned (so far) is every programming book starts out with "hello world" and this spread online not just to generic language teaching but into APIs and libraries.
Bootstrapping up from hello world is nearly guaranteed to work, write the entire thing first then try it is a recipe for pain.
If what you're building is pretty standard, it might work, especially if there's no performance element. Web type stuff can often be "take this widget and glue it to this page" in which case it's almost directly from SO.
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.
Probably because they're just manipulating some crappy, inconsistent API, or a buggy library. Nothing to figure out, just have to find the incantation that works.
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.
This is yet another trend following startup employer who doesn't get it. Really good, seasoned talent wants personal freedom (or more money and equity), and having an 'awesome culture' doesn't have to do with that.
Culture baits are primarily for 20-somethings out of college who don't know better or have nothing better to do. An example of giving developers real freedom: Let them work remotely for n months out of the year.
Yet few will trust developers with real freedom, because it seems too dangerous to most SV startup employers... and there is certainly risk there... But baiting developers with video games, pub trips, and secret cinema is just an extension of constraining said developer's freedom. If they don't care about that freedom, they are either young, in a tough financial position, or aren't top talent.
I don't know. I've been writing c# for years and I still go to SO for things. Sometimes it's even stuff I should know, like creating a text file. However I don't do some of these tasks often enough to remember by heart and it's not an exciting problem to figure out so I go for SO. I don't see a problem with that at all. I also don't get the sentiment that you're not a real coder if you use SO and copy paste code. I don't always have the luxury to figure out which sorting algorithm is fastest for the dataset I'm working with. Sometimes I have to meet a deadline. A great developer is one who writes easy to parse code that is as bug free as possible in the alotted time frame.
There are times when it's important to do some r&d and learn more, but there are also times when you need to ship. It really depends on what the task is. You can't paint the whole thing with broad strokes.
Way I read it the overuse of SO (along with C&P programming) thing was just one example/potential symptom -- he wasn't making a broad generalisation that all SO usage is bad.
I tell employers and employees and co-workers: I'm a good programmer, I'm a phenomenal Googler. I don't have to memorize the best sorting algorithms or how to create a text file in every language I touch. I know how to problem solve, choose the correct tools and search for guidance (note: that doesn't mean straight c&p always but could if it is appropriate) on things that get sticky.
I hope that's somebody's living quarters in the photo, and not their office! I've worked at a couple of offices that felt tightly packed, but they were nothing by comparison to that ;)
As a long-term proposition, I'd say that table is suitable for no more than 3. (Not sure what official guidelines are, but I'd say you'd need around 150cm x 75cm, or 5' x 2'6", per person. That gives you enough room for keyboard-laptop-monitor depthwise, and two monitors-plus-space widthwise. But the more the merrier, of course... humans are social, but not THAT social.)
>I hope that's somebody's living quarters in the photo, and not their office! I've worked at a couple of offices that felt tightly packed, but they were nothing by comparison to that ;)
That looks like a typical university hackathon to me. Certainly not excusable if it is an office. Thankfully my only workspace (at an internship) had nicely sized desks for everyone, and the company was looking to expand by renting more office space rather than decreasing desk space.
I've been to the offices that look like that - I always assumed it's a typical startup setup. Frankly, I probably wouldn't last more than a week in such conditions - I don't respond well to sharing personal space with other people for prolonged periods of time.
And doing serious development on lap tops realy! you need some decent 2 or 3 monitor set ups with a nice i7 workstations with some nicer mechanical keyboards and mice.
Yes I know you can get docks etc for laptops but its far more expensive for the same performance.
Just for ergonomics alone you should use a desktop setup over a laptop setup for any prolonged periods. It's as good as impossible to use a laptop and not be hunched over.
Or you could use a docking station with proper keyboard, mouse and monitor(s). Works great if you also need to attend some meetings or conferences from time to time.
Also, as a developer I don't need i7. SSD, great monitor, keyboard and mouse, and lots of RAM, yes - but CPU? Depends on domain I guess.
> Or you could use a docking station with proper keyboard, mouse and monitor(s).
Proper keyboard, mouse and monitor(s) setup is what I meant with "desktop setup". Of course whether the actual computer is inside a laptop, inside a desktop cabinet or inside a phone does not matter for ergonomics.
It's a London based startup, they all look like that until they get some serious funding - and some don't move beyond it even then. If anything, that's above-average.
What do these companies that don't move then spend the money on? Because it doesn't seem to be the salaries ;)
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.
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.
I agree with most of the management advice here -- addressing employees engagement and boredom is probably one of the most important things you can do as a manager, and often the fix is simple (new project, new responsibilities, whatever).
That being said..
You know that old saying "if you're bored than you're boring"? I think most programmers that like programming are able to keep themselves entertained most of the time, if they feel like they're building something useful. Even things that seem mundane often have their moments.
In my experience as a programmer, my engagement almost has nothing to do with tech stack or stale technologies, it has to do with how useful I think the project is, and how much decision making autonomy I've been given in my little zone.
I get the impression with there being a new in-vogue web framework every three months and database and whatever, that people are just seeking novelty. Programming has become much more democratized in the last decade, which means a lot of people that wouldn't have otherwise been programmers are involved. That's mostly a good thing, but it makes me wonder if a lot of this novelty seeking is because not-particularly-challenging work is being assigned to people that are not-that-interested.
Reads like a whiner to me. Gets bored and switches jobs every two years? Doesn't want to maintain anything not written by him when he can rewrite it? These are immature attitudes. I bet his rewrites introduce a ton of new bugs because he hasn't taken the time to understand what the old thing did.
Why? I'm bored with my job. What is missed is that you get bored with a company because they're treating you like a fixed resource. You get assigned tasks in your area of usefulness, which everybody takes for granted because that's all they've ever seen you do.
You ask for time to do useful things like work on the build system or refactor some stuff to use a new language feature, but because your boss is uncomfortable letting you branch out, they ignore you. You might get assigned some busywork documentation while all the real decisions are made after hours and with no input.
Essentially, you get bored with a job for the same reasons you get bored with an SO. They slip into a state of taking you for granted.
Too Long; Didn’t Learn
Maintaining legacy code is boring.
Copy/pasting is boring.
Internal tools are usually boring.
Being a code-monkey is boring.
The day-to-day always gets boring.
These things are usually true when you're not building something cool and meaningful.
These things are rarely true when you ARE building something cool and meaningful.
So...
Coding is boring, unless…
You're building something cool and meaningful.
That's pretty much been the way I've always seen it. Take OP's 6 headlines and add all the other stuff like:
workspace
equipment
boss
commute
money
and I still believe that if you're building something cool and meaningful, you put up with everything else and if you're not, you'll find a million things you don't like.
What you build is the issue. Everything else rest are details.
> Coding is boring, unless… you're building something cool and meaningful.
The problem comes when the people doing the coding don't consider the business goal of the software to be cool and meaningful. To everyone but the programmers, it doesn't matter what tech you use to build the solution if it's not solving an important problem.
So they start writing a web app with Backbone and then move to Angular and finally React without ever have created a viable product, but they feel good because they are using something that other devs feel is the coolest and most meaningful today.
I switched jobs a year ago: from a low paid startup job to a company that does project-to-project grunt work for local banks.
I (@Hisako1337) learned a lot during the past years, absorbed the whole mindset of Lean Startup, Customer Development and truly agile software development. I taught myself the complete fullstack, from User interviews to SPA frontend dev with advanced SEO, backend development with imperative, OO and functional mindsets (Love Elixir currently!), using different communication protocols (have a degree in distributed systems), and optimize solutions by using appropriate database solutions, from relational to document stores to graph databases. I even learned how to build desktop apps with web tech before it was as cool as today and currently I absorb every piece of machine learning material I can find/buy. Every bit of learning happens in my spare time, because: ...
Now guess what I do for a living for my current "FinTech" employer? Bugfixing a decade-old Spaghetti-architecture CRUD PHP app, doing pretty useless projectwork for customers (middle bank management).
I'm not allowed to improve things, because stuff might break and of course there are zero tests written. Boredom? I hate every Single hour at work. Most colleauges behave like braindead zombies. But the salary is quite good and I can't move to better job locations.
Others here might not believe that situations like described in this articles occur- but really- things can be fairly worse. I'd love having problems that are worth a question at SO, not the trivial gruntwork I'm supposed to do all day, with zero impact for anyone for idiots that have no clue but enough money.
Sorry for the rant- this article triggered a wave of emotions...
This is my life. The ancient codebase that doesn't use Objects because "They didn't see the point" with no unit tests. The pay is more than I could possibly hope to achieve at another employer in this area and, accounting for the cost of living, more than I could hope to get anywhere. I'm attempting to improve the place from within, but the long-term employees are resisting change.
I'd agree with most of the article except the "The day-to-day always gets boring" segment. If you don't like yourself, traveling merely results in not liking yourself somewhere else. If you are boring, going somewhere exciting merely results in an exciting place now including qty one boring person. If you don't like your job, being forced to participate in a hackathon will result in increasing the hatred of the job not loving it. The diversity part especially was racist, all brits are the same, all greeks are the same, there is more to diversity. Note how that section also neatly excludes all potential employees with social lives or family lives outside of coworkers due to the relatively intense level of required coworker socialization, yet categorized that very exclusion as diversity. This is especially striking on a holiday weekend, I had a lot of fun this weekend without a single coworker being involved, not even a phone call, so far anyway. It would suck from a stress standpoint never being able to get away from work, or having to give up holiday family time just to put food on the table.
An unmentioned advantage is there is some (ugh) synergy in the two separately described issues of elimination of giant monoliths and rotation of personnel. However, eliminating "can grok the entire system architecture" as a precondition of writing code doesn't mean nobody needs to grok the entire system architecture.
One way I've handled "Too Long; Didn’t Learn" professionally is to just fix stuff on a higher level. In the article there is an example of a boring inside tool acting as a "fake-Spark". Well why not just re-implement in Spark? The reason why not might tie into the other paragraph that paraphrases to "micromanagement is not fun", but just job hop until you find a professionally managed company then its all good.
I think it's great that the author tries to address high turnover rates by trying to make the company a fun place to work. However, I feel like he's taking the wrong approach.
It's certainly true that developers want to have fun, but I don't think technical decisions should be influenced heavily by what's fun but instead by what makes sense. For example, it'd be a lot of fun to rewrite an entire code base in Haskell or some other language I'd like to learn. I'd very much enjoy working somewhere that I could do something like that. On the other hand I wouldn't recommend doing that ever, because it makes very little business sense.
In my opinion, a much more reasonable approach to letting developers have fun is to give them more freedom in things outside of work. This could be giving them more free time (every other Friday off or something), or even letting them do personal projects to advance their skills on company time. For example, you could host tech talks where employees teach each other things they learned, and also give them time to learn new things, while on company time.
This seems to work better to me because this way your developers have a reason to stay: they will have a hard time finding another company that gives them these perks. On the other hand, you can keep your company's technical decisions influenced by what makes sense as a business.
Maybe I'm just very cynical, but work is work, and I understand that while working I need to do what's best for the company, not for myself. In the same way, your employees will stay if staying at your company is what's best for them.
Nevertheless, it makes me happy to see a company that tries to make its employees happy. I'm just worried that this method isn't really sustainable for the business itself, and if that's the case then I don't think other companies would follow suit.
I think there's something to be said for the Google model where you combine a good work environment with a time-splitting technique that allows a break from main projects. Many top projects in the company started as someone's 20% time or whatever they called it. Far as the perks, we don't have to go far as Google but a subset could certainly help.
I don't understand how good programmers can have boring work.
Any work you have that's not interesting is work that should have be done by a computer for you. If your computer can't trivially obtain and solve the work, the interesting work clearly isn't done.
Just using tools or applying well-known solutions to known problems is boring, sure. But that's operational work. I believe our job is to eliminate operational work by building better (at the omega point, fully automated) tools.
Let me walk back that a bit - there's an exception. A good programmer can have boring work if their managers forbid them from building the tools necessary to reasonably do their job. I had a job once that did exactly that; they were happier with the status quo because with the setup they had they needed N hours of programmer time for every customer-feature launch pair. When I showed them how we could reduce it to approximately N hours of work to add the feature to every customer's instance, I was told no, because as it those N hours spent on each client's site were billable hours to the client. In other words, that I was reducing the total work needed by a factor of the number of customers to provide the same value was seen as detrimental to the business.
Their business model was broken to the point where it favored operational work over engineering work. Hours spent working were more important than results delivered. I was only at that job for a couple of weeks; pretty much exactly when they told me that they didn't want me to reduce my total workload because of their billing structure was when I decided that I'd be leaving. And I have zero regrets.
So, allow me to rephrase: I don't understand how good programmers, given the autonomy they ought to have, can have boring work.
How does salary come into this? You'd think people would be able to stand the boredom a bit better if they got paid more.
For instance, I know people in banking who are getting 1200GBP a day doing nothing special in some Java CRUD. But it's not that easy to find something interesting like what you read about in startup land that pays nearly as much.
Thanks. I have seen four figure contractor rates at a well known British bank on CW for senior team lead devs. And I've got first hand experience of four figure rate cards as a consultant with a "boutique" consultancy myself. I know that day rates for Python contractors at banks and hedge funds are healthy recently as I get a lot of agent calls. I guess it's an effect of two things: firstly, a lot of the banking work is driven by regulation, and so is really boring. Secondly, lots of startups drawing the best devs with decent salary + equity.
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.
> The company hasn't been around for the same length of time that the author says is usually when he gets bored
This is the problem with some people. They worry so much about the latest technology that they forget to just get stuff done. The company might not even last long enough for engineer turnover. Just do things instead.
Off topic: I don't know a single feature that would be as annoying as fucking toolbar/header/whatever showing up when you scroll upwards. Why everybody does this?
I agree, although, it’s not as bad in this case. I find it far more annoying on sites where the header is always there, as it breaks page down / spacebar functionality (when you page down, the header will cover some unread text).
Makes sense in Facebook mobile app, where you often actually want to use the toolbar (it lets you create a new post). Elsewhere, I don't know. Probably people copying UX solutions from other people without thinking about whether they're needed.
This doesn't work in the long-run. I'm an independent consultant and when I was just starting out I had the same thoughts. And it was great to be in full control and always use the latest shiny new things.
However I eventually got shiny new fatigue. In the long-run, the real thing I found motivating was completing valuable work for clients in the most efficient way possible.
And perhaps that's the true reason OP has found coding boring in the past. Not because of anything he thinks are the reasons, but because he's worked at too many places with inefficient management and poorly-defined projects. If so, new-shiny is only a bandaid on the root problem, and the real solution is to ensure projects are well defined, understood to be useful, and well-managed before a programmer ever even sees it. New-shiny may make it even worse in the long run.
AND...microservices??? I can't imagine a scenario where the benefits outweigh the cons for as small a team as he's got. Of course they're all the rage and people get into microservices for all the wrong new-shiny reasons, but escaping boredom has to be the worst one I've ever heard.
> In our team, we try and prevent anyone from working on the same code, product or dataset for more than three months. This period is a bit arbitrary and perhaps too short for larger companies. But we generally believe in fast rotations.
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.
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.
The business exists to make a profit, and it needs to perform financially as well as possible this quarter.
That does not always align with what is most interesting for a developer to pursue.
So in the short term and medium term, these goals are usually at odds. In the long term, you can find harmony between them sometimes if you try really hard.
It's impossible by definition for them to be in harmony all the time. Too bad, but that's reality. Each individual developer has to occasionally re-align them by making a job change.
Fixing bugs in poorly designed/written code is the number one cause of unhappiness for me. Maintaining my own code is fine, at least it is a learning process to see what worked/didn't work in the original design. Instead of letting everyone rewrite the legacy code with a new language/framework, I think the solution should be that each developer needs to maintain the code they write as much as possible. Maintenance work should be properly rewarded and project ownership should be promoted.
>A key ingredient here is diversity: hiring people with different backgrounds and origins (e.g. our team of 6 is currently British, French, Russian and Greek). Seeing the same people every day is definitely more interesting if each of these people can brings something different to the culture.
That is why remote work exists, so you can change your working environment by traveling to different places and then learn different cultures. That keeps you away from getting bored.
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.
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 ...