Save your Cleverness | Hacker News Reader

Save your Cleverness

tirania.org

126 pointsDanielRibeiro34 comments

I tend to agree with the sentiment here; I like to play around with new ideas/stuff/software/architecture, and constantly look for way to make use of it day-to-day.

But if I've decided to take on a new project it's best to default to my usual stack (PHP (Kohana), MySQL Nginx) and rattle out the basics. It makes a lot of sense to solve a "hard problem" in an environment that is second nature to you; too many projects flounder because as well as the project you're also dealing with a new architecture.

(this is why I always dislike this idea of using a project to learn an language... it never works out)

Actually, as an example of this, I've been working on a new project at work recently which uses PHP/MySQL - but I've been looking into packaging it as a VM appliance, and the considerations/work related to that has put me about a week behind getting the actual project done.

>(this is why I always dislike this idea of using a project to learn an language... it never works out)

How than do you learn a language?

I learn with pet projects, i.e. stuff that doesn't have anything to do with deadlines or customers.

This.

For most of my hobby projects, learning a new language is the main goal.

Small tasks, the tutorials. All sorts of ways.

But if you're learning Ruby, writing a Rails app is not necessarily a good way to start. And if you are learning Rails writing a full on project as you're introduction is going to flounder.

It depends - Rails has so many conventions used (magic behavior) that, while useful, you have to learn them all and even how to override that behavior, before being able to tackle anything else other than simple blogging software; although the learning experience is enjoyable.

On the other hand Django is an (arguably) thin layer on top of Python. You can start from the URLs specifications and how to construct a simple HttpResponse object. And that's all you need to know and how tutorials teach it -- for everything else you can rely on your previously learned skills, while learning shortcuts on the way.

For another perspective -- Rails learning is top-down, while Django is bottom-up.

Yeah, I definitely learned way more about Ruby when I used it to automate a set of tasks (like my build/push process) and writing something minor like a twitter bot or a text parser.

Using Rails on a larger project is good as far as learning a framework, but to get into the language and get into the cool/weirder stuff I've found small projects do the trick.

I tend to agree with you, but at the same time I find that tutorials and even side projects often don't move past the fairly basic usage of a language or framework. So even when I think I have learned something well, I end up having to work through a lot of unforeseen issues while working on a real project that end up being more time consuming than learning the basics. So in some ways I feel that the only way to really learn a new language or framework is to use it on a real project, because that's the only time the real challenges are going to present themselves.

I could be way off though, maybe I just need way more ambitious side projects.

Telling people to take shortcuts and write spaghetti code is a terrible idea. I'd venture to say the people nodding their heads have never had to deal with a million line code base with spaghetti code, duplication (50%), terrible architecture and no unit tests. How do you think it got that way? "We got a new client! We need X functionality right now! You want to re-architect? We don't have the time!" etc... etc... If your product is never successful its a moot point either way. If it is, you better damn well hope you have free time to both expand your product and re-architect it.

I'd much rather see a sentiment of "never sacrifice architecture for functionality but never let architecture drive your features."

The more I learn about entrepreneurship, the more I come to realize that writing the spaghetti is the way to go. Writing software quickly is much more important than writing it well. Of course, when you have a product that makes money you'll have to rewrite it, but by then you will have money to pay for developers... How do you think Facebook was created?

"Writing software quickly is much more important than writing it well" You should mean: "Figuring out if people will use your product/idea is much more important than programming it"

At this point in my life I can implement a well-programmed solution much more quickly than spaghetti code. Additionally I'd rather be proud of my work considering 99% of the time I will be failing at creating a successful product. If you care that little about programming then find someone to do it for you, but if you are actually a developer then I don't understand this haphazard approach. But then I suppose people are naturally lazy.

If you are coding as a means to an end, then by all means spaghetti code, but if you are actually coding because you like to code and subsequently like to create, then for the love of God take pride in what you do! This Black or White approach just does not make any sense in today's technical world.

> Writing software quickly is much more important than writing it well.

I would say that releasing software is more important than continually delaying for amorphous "quality" concerns, but this is backwards. You want to write quality software. I've been on several teams that valued speed over quality, and in the end we always end up with a sad, fragile bit of software that's hell to maintain or add features to.

> Of course, when you have a product that makes money you'll have to rewrite it, but by then you will have money to pay for developers...

Again, having been part of teams that operated this way: later never comes. Paying customers means people relying on your software. You can't just stop working on it to rewrite from scratch, and their bugs/issues/feature requests are far more important than refactoring (which they'll never notice.)

If you ever want good software, make it good from the start.

I really hate spaghetti code, but that is because I'm a developer. The sad truth is that the reason a lot of developers like you are hired to work on this kind of team is that somebody was smart enough to release software quickly and make a business out of it...

I think spaghetti code is fine, so long as you know you're writing it and that it needs to be rewritten sooner rather than later. I often need to prototype an idea, so I can test it and show it to others for comments, before I know whether it's actually an idea worth pursuing.

Fortunately for me, smart people were having this same discussion 10 or 15 years ago (just as I got to the age where I stopped thinking I knew everything), and interestingly referring to Fred Brooks' work, presumably from the late sixties:

http://www.webdeveloper.com/cgi-perl/cgi_perl_style.html

"Think first. Then hack. Now throw it out. Repeat. Fred Brooks says, `Build one to throw away.' Always rewrite your code from scratch, preferably twice. just as did it with drafts of papers in grammar school. It improves understanding, gets the creative juices flowing, and produces a far finer end-product."

I totally agree with the sentiment, and I have always valued Miguel's work and opinions.

But this man started to work on a .NET clone as he was fed up with working in C for Evolution -- if building your own compiler when nothing else matches your needs and desires is not the ultimate form of yak-shaving, I don't know what is :-)

That's a yak-null; a first-order yak-shave.

Building your own hardware to build your own assembler to create your compiler to build your own OS to allow you to build your own CAD system to create your own board layout and test tools to build your own processor to create an assembler to...

There's always room for a higher-order yak.

You mean like Chuck Moore, the Chuck Norris of computing?

Chuck Moore written backwards is still Chuck Moore.

You may have it backwards: Chuck Moore doesn't compute. He tells electrons where to go, and they take orders. Inside every computer built by Chuck Moore, there is only another computer built by Chuck Moore. Chuck Moore once built a zero-instruction chip that always produced the correct answer. According to a doctor that wished to remain anonymous, Chuck Moore has only two internal organs: a whiskey processing unit, and a NAND gate. Chuck Moore once traveled back in time just to convince Alan Turing that his computer didn't need any I/O devices besides a tape reader.

SCNR

Author is right on. Reminded me of http://news.ycombinator.com/item?id=2329105 - drawing the line between work, play and deliberate learning.

How do people deal with staff who are quite clever, but write very complex code? I know a person who is a very good engineer in that he understands the underlying principles, but writes horribly complicated code. I'm trying to get him to write simpler code, but haven't succeeded so far.

Usually, it's a phase. Right after one acquires what could be called "mastery" of a language there's a period where even the most complex (or obtuse) ways to use the language seem simple.

After a while that high subsides and one starts seeing the elegance of simple solutions for most things and complex ones where it's warranted.

I've seen this before on the other end. Someone learns a mostly useless design pattern then begins to architect every solution using it.

Start by talking to them about how you think they are really good at solving problems -- and how one of the challenges you hope they can solve is producing work that others on the team can understand and extend. They may need to first hear you acknowledge that they are talented and that you admire their work -- and then that you wish their work was more accessible to the rest of the team. The idea is that most good engineers will want to produce work that others can understand and appreciate. You just need to make it clear that you consider that part of the domain of problems they should be keeping in mind.

If this goes well, you might also want to acknowledge that this may mean taking less sophisticated, less forward-looking approaches. A lot of over-engineering is like over-training a model to historical data, assuming the future will be exactly like the past. Anyone who's worked on software for very long will be acutely aware that needs change over time.

Thanks all for the comments. I've tried all those approaches, but failed so far. I'll keep trying.

Miguel plugs "Why Programs Fail." Does anyone here second that recommendation or have an alternative? I'm about to buy it, I think.

Okay, I agree with the basic principle.

But why is it every time somebody writes a piece about focusing on the "stuff that really matters", whether it's the user experience, or actually shipping stuff, it always sounds to me like an excuse for taking unnecessary shortcuts? Since when is dependency injection a "fad"? What the f* is wrong with writing unit tests?

Or in other words, what's wrong with building half-decent code the first time around? It doesn't take much more time and it makes refactoring afterwards so much easier. Using very common basic best practices when coding has nothing to do with over-architecting or trying to be clever.

Dependency injection was a fad. Pretty much every framework under the sun started using it and exposing it in the API and now it has more or less fallen out of favor, giving way to other fads such as framework metaprogramming. Following fads has little to do with writing good code the first time around. Good code is code that gets the job done, has some modicum of maintainability, and didn't take you 10 years to write perfectly the first time.

I believe all of that is fine, the problem is spending too much time on it. For example, writing comprehensive unit test may be not much better than having just a few, because there is no way to test for every possible bug. Also, in some situations it is better to have code with a few bugs than no code at all.

Unit testing is more about documenting the expected behavior of software, not necessarily to test every possible contingency.

If you want to write dirty code on an initial run, and refactor later unit tests will help out a whole lot.

what's wrong with building half-decent code the first time around?

It violates the spirit of MVP. While all ideals (MVP, DRY, etc.) should only be guidelines, they do have an effect on priorities. Simply said, shipping usually wins over everything else.

Last company I worked for got excited about dependency injection. Only problem is that only one developer really understood it. Then he quit.

Testing code - good. My mantra is "if you haven't tried it, it doesn't work".

Writing unit tests - usually takes too long. Shipping can happen 25% faster if you hack and adhoc-test and prototype like mad.

Its a question of process - and in a startup there is time for very little.

Take the shortcut. Build the product. And if later, it turns out you made a design mistake, refactor the code. But at least you will have a product that your users love.

This doesn't seem to be working with me. When you re-factor a part of your code, you are probably doing it for optimization. When your architecture is broken and you are going dark, I don't think you can still re-factor your whole code base and keep your customers happy. (Deadlines, bugs, downtimes, costs...).

Reply on news.ycombinator.com