A Programming Hobby | Hacker News Reader

A Programming Hobby

marco.org

48 pointsmh_34 comments

I think building stuff is hugely underrated. When I look around most people are working on stuff that concerns being interfaces to complex systems (lawyers, doctors, customer service), communication (formal and informal jounalism, technical writing, making data comprehensible), or management (making projects happen).

There are, of course, much pleasure in these things, but what I enjoy most is building and releasing new "stuff" into the world. There is perhaps something primitive about building articfacts that give you pleasure, enhance your life, or make you more productive.

Building things is awesome. It's too bad that the people who get more respect tend to be managers. Think Jobs vs Woz. I bet a good number of apple users don't even know who Woz is.

To be fair, Woz hasn't had direct involvement with Apple (other than as a shareholder) in decades. He's definitely not responsible for "new" Apple.

"In many ways, I always kept my distance a bit, never caring much for advanced methodologies, studying design patterns, proving algorithms, or learning cutting-edge languages before they’re stable and practical. I’ve always written code for the sake of making the product I wanted, not for the code’s own sake."

Refreshing to read something like that here on HN, especially when you share this instrumental approach. If I remember correctly, DHH also said something along those lines somewhere.

So did Rasmus Lerdorf. Ick.

I prefer a hybrid - choosing to care about the craft and take it seriously, but make the improvement thereof useful to producing things.

PHP originally stood for "Personal HomePage tools". My guess is that it was never meant to be what it is today.

While PHP has some rough edges and language level design flaws, it supports everything one needs to write structured and well designed code.

This PHP hate shit is just stupid.

Disclaimer: I use python.

It was definitely never meant to be what it is today, and that's one of the reasons that most informed people with a choice choose not to use it. It may support everything one needs to write structured and well designed code in theory, but it makes it far easier to write poorly structured and poorly designed code. I've never seen a real-world PHP codebase that wasn't a disaster.

Then you looked at the wrong projects. Look at a Symfony2 or Zend Framework codebase (which are the most popular frameworks) and you wont find much of a difference to Rails or Django. Imo Symfony2 is better structured than most of them.

Little known fact, PHP was created by a grad student from Miskatonic university.

Linux was created by a student, too.

Google "Miskatonic" so you can be in on the joke.

Ah self awareness is a curse. I can certainly relate to Marco's and by reference Matt's struggle.

Early on in life there is the ever present exchange "Hi, I'm Chuck I <foo>" where <foo> is some tag, some referent, that hopefully is common with the person you are talking too and that sets up a series of linkages, defines behaviors and expectations, and can inform on conversations that may or may not be interesting. When I was in my mid twenties I realized I was saying by rote "I'm an engineer." And that would then grease the conversation along.

But after a while I had things I did at work, and things I did as a hobby, and things I was interested in, and had a few awkward sort of exchanges that went something like "Hi I'm Chuck, I'm an engineer" ... various technical discussions ... "what do you think of the hypothesis that petroleum is a biologic process?" ... pause ... "Uh, I thought you were an engineer."

Then once I realized the conversational rut I was in I started just cutting it off, "Hi, I'm Chuck."

Now that is really funny around introverts since you leave them with no place to go. And a lot of folks I socialize with are fundamentally introverts. So that isn't a good conversation starter. :-)

But once you realize its a conversation starter, not a definition of who you are, you can go back into discovery mode, like "Hi I'm Chuck, I'm curious about that gizmo you're carrying ..." etc.

And you realize, as Marco and Matt have you want to know "who" you are. I've decided I'm the equivalent of the 'curiosity' thing you pull out of GLADoS in Portal.

Yeah, but is it really that complex? You could "I'm a software engineer" or "I'm an electrical engineer" and the it doesn't have to go into aquifer building or whatever. Anyway, I don't really think it matters.

Programming is to Software Entrepreneurs what Mathematics is to Architects. Means to an End.

There's a great pun to be made here involving mid-grade professional killers being the means to an end, but I can't seem to formulate it.

I'd argue that programming is a lot more core to anything software than mathematics is to most architectural firms.

I think this not true. When you say "Software Entrepreneurs" I feel like you are thinking of it only as a set of people trying to make quick photo sharing apps and sell them for a $1B valuation. There is a large amount of software "entrepreneurism" where programming is more than simply a "means to an end" ... unless we reworked your example as " ... Architecting is to Architectural firms" ... sure on some level the firm is more interested in getting their clients separated from their money, but architecture is prime part of it.

When people say Software is eating the world. What does that mean ? Software is being used as a tool in many different domains to solve problems. I think people who focus on software development to serve software development is in the minority.

It's a cute thing to say is all that really is. It's also fun to say that a "A lawyer's job is winning cases for their clients. Using the knowledge of the law is simply a means to an end." But the reality is two, the goal and so-called "means" to achieve the goal are closer aligned than you suggest.

Sure, OK, perhaps for a very simple SEO based scheme software product, maybe the "programming" is a trivial part of the whole deal.

On some level, it's like a fruitless discussion. Unless, you or anyone seriously claims that for the majority of software, the actual programming is really trivial or tertiary part of the process, then you would just be wrong. Otherwise, I don't really see what the usefulness is in debating programming as "simply a means to an end."

Sounds like Marco is in the same place I was in my late 20s: burnt-out.

How did you end up moving past that (assuming you did)?

This could be the subject of an entire series of blog posts. Look up adrenal fatigue; which is a controversial and not medically recognized diagnosis. I basically followed the approach others have outlined.

I didn't take the gingko, black liquorice, and pig adrenal tissue cause that wasn't a thing in 2008. But everything else. Remove toxic people. Quit your crappy job. Remove dreadful stuff from your TODO list. Tea instead of coffee. Sparkling water instead of booze. Sleep a lot. Do yoga. Figure out which foods upset your digestive tract (for me that was dairy and gluten).

Burn out is a real thing and almost every person I know in tech that has been doing it for a while has dealt with burn out.

I hope to write out my thoughts and experiences but I'm wary because I want to be helpful without coming across as a medical professional, a new age guru, or a self-help blogger.

I'd love to hear more. I've been through this more than once and don't have a good answer on how to get out.

Yes! The tools are a means to an end. The goal isn't to impress other developers with advanced knowledge of design patterns. The goal is to impress users. If your products impress users (which Instapaper and Tumblr certainly have) I think that makes you a damn good programmer.

I disagree. It's completely possible to impress users while simultaneously writing code that is abhorrent. It makes you a good "UX guy" I suppose, but not a good programmer.

If you have barely touched code in 6 months, you are not a programmer. Moreover, if you haven't bothered to learn design patterns, you probably never were.

Design patterns are weaknesses in the design of programming languages: http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...

Something about this bothers me. Let's say Donald Knuth hasn't coded in a year, maybe's he's been busy with this and that ... You consider him not a programmer ... maybe that is too obvious and example but also design patterns ... I have hard time accepting that as well ... I would agree there is something anti-intellectual in being dogmatic against learning them ... but I suppose on some level it depends on what you mean. This can be a contentious topic; are you saying that if you are not friar in the mission of the Gang of Four that you are not a programmer?

In my attempt at brevity I fear I lost some context. I do however firmly stand by if you are not actively coding, you are not a programmer. What the exact timeline is, I will gladly leave up for debate, but it's not like riding a bicycle - you lose ability over time.

As for design patterns, I think we are in agreement (at least in principle) about their worth as a starting point. I am not at all saying that GoF (or any other design pattern text) should be followed. Rather, that anyone seriously considering themselves a programmer should have an understanding of the design patterns that are pertinent to their language/methodology, and hopefully their own opinions on which make sense or not.

I likely have too high of a standard for the term programmer, but feel it has been steadily lowered by this type of talk and wanted to at least try to move the bar back up.

but it's not like riding a bicycle

Interesting tidbit on this concept. When I was 17 I had a cycling accident where I flew over a car and landed on my hip quite badly. I gave up the bike for ten years (wasn't a huge fan anyway), then eventually thought I better get a bike again. So after not riding for ten years, I had a bike out on a test ride in a side street, and on that first-ride-in-ten-years, I was riding quite happily hands-free. There really is something to not forgetting how to balance on a bike. I decided not to push my luck and resumed a normal pose before I reached the speed bump though...

So, I occasionally hear someone espouse the utility of design patterns. As a Haskellite, I tend not to see the point, and wonder sometimes whether they're all just kludges to, e.g., work around not having first class functions. I've actually written more Java than Haskell, and have taken a (not great) class on design patterns, so I'm aware of these concepts; I'm just yet to see the point.

Is there a good explanation of design patterns conducive to a "functional" programmer's point of view? Most importantly, one that doesn't motivate the problem in terms of objects? (Objects in the solution are fine, but if the problem only arises when you use objects I might as well go back to Haskell.)

The one pattern I know holds its water is the Visitor pattern.

Yes, you're looking for Norvig's "design patterns in high level languages" presentation, here:

http://norvig.com/design-patterns/

Fair warning: it reiterates Rayiner's point upthread.

That is precisely what I was looking for (and from Norvig, no less). Thanks!

I think the observer pattern can be useful as well (though there are definitely alternatives), but for the most part you're right. Factory pattern et al exist to solve problems that are introduced by OO. Get rid of OO and you no longer need to solve those problems, though of course you do still have to solve the problems that OO was introduced to solve in the first place.

Visitor is just a kludge for multiple dispatch.

Reply on news.ycombinator.com