Live data from Hacker News

Coding is boring, unless

blog.enki.com

121–130 of 158 posts

Re: Coding is boring, unless

#121

Earlier quoted context omitted.

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

> it happens to me occasionally, but I quickly get over it By realizing that you'll make even bigger of a mess the next time around?

AKA The Second System Effect. :)

https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sec...

Re: Coding is boring, unless

#122

Earlier quoted context omitted.

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…

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.

Re: Coding is boring, unless

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

Re: Coding is boring, unless

#126

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

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.

Re: Coding is boring, unless

#127
post #75

Earlier quoted context omitted.

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 u…

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…

"Python for impunity"

I was wondering why I keep seeing this everyone. Python this, Python that.

Re: Coding is boring, unless

#128

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

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 dev…

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.

Re: Coding is boring, unless

#129

Earlier quoted context omitted.

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…

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

Re: Coding is boring, unless

#130
post #117

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…

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.
Post reply on HN