Hacker News Reader

Comment by alkonaut | Hacker News Reader

It completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. If the product is Doom this shouldn't be a problem - but for most of us the product is form validation or calculations involving plywood. Making frameworks and generalization is the only reason I manage to keep doing what I do. (I'm exaggerating somewhat, but I think this is a clear distinction between two kinds of programmers those who love the code; and the craft, and those who like making products. Have too many of one kind and you'll ship a mess. Too many of the other and you'll never ship)

View on HN

Generalisation is always needed in a code base. However, only generalise pieces that you actually use in your code. YAGNI (You Aren't Gonna Need It) is a great principal. You should follow it -- until you need it. Then, of course, do what you need to do.

People often think that projects get slower as code is added. However, the systems we work with are dramatically more complex and based on more pre-existing code than ever before. Because that pre-existing code has been generalised out, we can write new code easily and quickly.

There are two situations that you need to think about wrt to this issue (IMHO). If someone needs to do something that you have already done in your project, it should be simple and obvious how to do it. The more often something needs to be done, the more simple and obvious it needs to be. However, if someone needs to do something that hasn't been done before (even if it is is very much related to what already exists), then all doors should be open. The code should not imply how new work should be done. It definitely shouldn't try to guess what you want to do and do it before you get there.

>> Making frameworks and generalization is the only reason I manage to keep doing what I do.

<sarcasm> This could be written on the tombstone of JS. </sarcasm>

I hate writing boilerplate and I'd rather have pineapples shoved up my behind than write code of the kind that should be in the freaking standard library.

But yeah

This is what always bugged me about java. I'm only just above a beginner, but it seems to me that in 2017 you shouldn't have to write so much crap just to read from a file.

BufferedReader, FileReader, blah blah blah

http://www.mkyong.com/java/how-to-read-file-from-java-buffer...

Maybe there's a good reason to make it this difficult, if so I'm not aware of it.

There is - but there is no good reason to not have good naming plus also a simple wrapper to do the most common cases. That the IO framework is very general is good, but that you need tons of boilerplate for a common scenario is bad. C#

  var txt = File.ReadAllText("file.txt");

This is exactly the abstraction you want if you want to read a (whole) text file. The point of abstractions is to pick the right one. For IO it's likely best to have many layers of abstraction so you can choose the simple top level function or use a more complex one when needed.

I'm sure there is something similar in Java these days too. Would be a huge mistake to not have simple IO helpers to the std library.

Like this?

https://docs.oracle.com/javase/7/docs/api/java/nio/file/File...

Something like that, though the method to read a whole file into a single string seems absent for some strange reason.

I have seen projects drown to death in a sea of frameworks, supposedly reusable libraries and generalizations developers deemed necessary. But it was fun for some, I am sure.

I've seen projects fail for a variety of reasons. A few fall under scenario you described. But, I've also seen quite a few projects succeed by making use of in-house developed libraries and frameworks. It probably more depends on who is on the team than whether or not the code is written to be generic enough to apply to other problems.

e: fixed typo

No doubt that's often the case. And depending on which type of programmer you have too many of, it might be failing for that reason or the opposite (insufficient generalization).

If you ever think "we are on schedule and this codebase has just the right balance between getting things done and doing it right" then you have a well composed team.

Generalise to the simplest expression of the logic of your application. Don't generalise towards the expression of the logic of all future applications.

The article kind of already says this:

  > Keep your code absolutely simple.
  > Keep looking at your functions and figure out
  > how you simplify further.

>It completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product.

Then maybe that programmer should go into teaching instead?

nope, I've delivered considerable value to my team by essentially letting the people who enjoy shipping end user features do that, and extracting frameworks and libraries so that the overall product stays coherent and easy to work with, or occasionally stepping in and saying "why don't you let me build the general pieces for this feature first, and then you can use them to make your life easier". as long as you have a decent feel for yagni, it's a useful role to play.

> go into teaching instead?

if teaching earned me as much as a commercial programming job, then yes. Unfortunately, most teaching positions are fairly poorly paid (compared with the qualifications required and the opportunity cost). That's a sad fact, but one has to consider it.

You have that backwards. People who don't enjoy these things should go in to management

People who enjoy actually building and shipping something instead of creating abstractions should go into management?

You do realize that this includes all the hackers with the original sense of the term, which are not about finely tuned abstractions and design patterns, but about creating things and hacking/kludging it out to get there faster?

"...only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product"

Too many projects suffer immensely because of people who don't give a shit about delivering. In that mode, anything is an excuse: we need to reactor, we need to build a better framework, we need to revisit the requirements, etc.

Then real progress gets slowed down because of some ill fitting development philosophy that some of those folks pulled out of their asses.

What you need are wise programmers that care about delivering product, wise enough to balance long term maintenability and code health with actual delivery schedule.

The keyword is "wise".

Of course I take some pleasure in delivering products, and I try very hard to not over engineer or over generalize. I take pleasure in it, that doesn't (necessarily) mean I overdo it.

But if the job didn't have those elements I wouldn't be in it - and our product would be suffering from that too.

Wise devs are hard to come by.

I thought I was the only one. Thanks for taking off a load of guilt. It's okay to enjoy this stuff. Very sage comment. Never finish because of the fun of building.

Exactly. e.g. it might be much easier (for some) to come up with a finished product/Game with Unity, with mouse clicking here and there... But it takes away all the fun of game development. On the other hand, I'm pretty sure it is hell a lot of fun working on Unity itself... So all the sweet is for their in-house devs :) (Same goes for Rails, Node, .NET, etc...)

I've never thought of it this way. While I don't necessarily agree, I'm thankful for this insight.

Reply on news.ycombinator.com