Live data from Hacker News

Coding is boring, unless

blog.enki.com

61–70 of 158 posts

Re: Coding is boring, unless

#61
post #46

Earlier quoted context omitted.

The business perspective shouldn't overlook the direct and indirect costs of engineer turnover.

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.

> Aren't these vagabond workers destined to leave anyway?

Even if not, they may not be paying attention to things that matter to your business, and may ultimately do more harm by staying.

Re: Coding is boring, unless

#62
post #38

Earlier quoted context omitted.

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

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…

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

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

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

Re: Coding is boring, unless

#63

> 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. Th…

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.

Re: Coding is boring, unless

#64
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.

Re: Coding is boring, unless

#65
post #31

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…

what happened to that dev lead?

Re: Coding is boring, unless

#66
post #46

Earlier quoted context omitted.

The business perspective shouldn't overlook the direct and indirect costs of engineer turnover.

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.

Re: Coding is boring, unless

#67
post #58

OP claims: Too Long; Didn’t Learn Maintaining legacy code is boring. Copy/pasting is boring. Internal tools are usually boring. Being a code-monkey is boring. The day-to-day always gets boring. These things are usually true when you're not building something cool and meaningful. These things are rarely true when you ARE building something cool and meaningful. So... Coding is boring, unless… You're building something…

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

Re: Coding is boring, unless

#68
> A key ingredient here is diversity

And all of the employees are white men. Yep.

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

Re: Coding is boring, unless

#69
post #9

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…

Well, startups are scrappy.

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.

Re: Coding is boring, unless

#70
post #38

Earlier quoted context omitted.

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

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…

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.

Post reply on HN