He's doesn't like the shape of the phone for playing games for an extended period of time, so he's hacking up a pretty sweet setup. I'll post up when it's finished...
In fact, I introduced him to 3D printers when I started reading Makers and he was absolutely blown away. He literally could not believe it it was real. He has sketches of many things he wants to build.
I bet he would really benefit from all of the different fasteners and replacement parts that you can make. There are lots of great inexpensive printers on the market right now! We're trying to make the software easier to use because it's one of the biggest barriers to entry right now. I'd love to get in touch with him tom@printtopeer.com
Clicked it expecting some rubbish. Left in amazement at this guy's ingenuity. I always find it incredible when people can repurpose stuff like this because I usually need everything just right. This is great.
I loved the story, and I wish I was still living in my old apartment, where I'd done similar stuff (though not to the same extent!). So much fun to repurpose things!
I was hoping he'd find some way to double-hinge the wardrobe door so it could function as both a door and a desk! Still obviously very cool and far more than I could do (or more importantly, as you say, even come up with).
Wow, that's awesome. I only wish I had anywhere near that capacity.
Unfortunately, I think my developer mindset actually makes physical hacking a lot harder due to 2 phenomena:
1. Code is cheap. Materials are not. I'm used to being able to churn out additional code with basically no cost to get things done, not to repurposing existing code (this is different from refactoring to abstractions).
2. Laziness is a quality in software development, but a major obstacle in physical development. I'll quickly abandon physical projects because I can't find an optimally efficient hack to finish things in minimal time.
As a software dev remodeling my house, I agree. It's been very hard to accept that all these learning projects are going to be redone three times, just like how I treat software.
I'm wasting wood! OMG! But I've made progress. Watching contractors has helped. I was astonished how much they waste, treat things as disposable. My father (a hardware guy) certainly would not have approved.
I'm framing a new closet with bypass sliding doors. I really have no idea what I'm doing. I knocked apart the first two attempts and hope the third works better. And I'm now okay with it. It's been kinda fun.
When i was taking my first programming related class, algorithms, the teacher told us we were like architechts, there shouldnt be errors/failures.
Is it accepted for them to say: whoops building fell, guess i'll rebuild it?
While software can't be perfect, it has to be as flawless as possible. Code isn't cheap, it takes time. Who knows what else you could've built/made/learnt instead of fixing something cuz it costs "nothing"
> When i was taking my first programming related class, algorithms, the teacher told us we were like architechts, there shouldnt be errors/failures. Is it accepted for them to say: whoops building fell, guess i'll rebuild it?
That's an absolutely terrible approach to software development. You can test a program as many times as you want before releasing it, but there's no equivalent iterative process for making a house.
If you develop with that attitude, you'll never get anything of real value done. After all, "le mieux est l'ennemi du bien."
Apples and oranges when you jump from algorithm design to software in general.
An algorithm has mathematical underpinnings and can be created entirely on paper first. Turning ideas into applications however is drastically enhanced by prototyping extensively.
Agreed. If you have the wrong algorithm, it doesn't matter how well you implement it: it'll still give you the wrong answer. But no matter how right your algorithm is, if your I/O doesn't work properly, you'll still get the wrong answer. And that's just for things involving a single algorithm; if you're talking about the larger piece of software as a whole (since a lot of programming is not algorithms, algorithms is just one of the harder parts), testing and prototyping and all that becomes even more important.
I'm living in my second house that an engineer has owned. Avoid their ex houses if possible. The side gate had a post concreted in with a block 75x75x75cm. I had to get a drain though it. A week of evenings with a sledge hammer. I excavated 10 tons of concrete from the front yard that was buried there for some reason, and it stopped trees growing. I got guys in to do the 90 ton slab in the backyard. The previous house had a raised garden that was in the way that was made of 30cm thick reinforced concrete - 2cm thick rebar to keep the roses in. It was days of work to remove the small garden. Durability is one thing, but over engineering is damn expensive pain in the arse.
Errr, you don't have to frame a closet three times to get it right.
Like software devs, you can do a lot of learning without waste.
Framing lumber is cheap, but that's no excuse to waste so much.
Contractors do it because they are charging other people for materials :)
In your case, if you are going to be remodeling your house and doing structural carpentry, i'd recommend "Renovation 4th edition" by Michael Litchfield as a starter book.
Also if you start doing something with more expensive lumber, like say, very high end woodworking, you will see nobody treats stuff as disposable.
The two challenges I have are assumed knowledge and lack of skills.
I've read the books, watched the videos, read the codes, helped my handyman friends. There's no substitute for DIY.
For the closet, I make a lot of little "learning opportunity" mistakes. I didn't make sure one of the header boards was truly true. I put 3-1/4 inches nails clean thru. Lots of trial and error with my spiffy new nail gun. Etc.
As for the software, I must be doing that wrong too. I'm always rewriting my own stuff.
"The two challenges I have are assumed knowledge and lack of skills.
I've read the books, watched the videos, read the codes, helped my handyman friends. There's no substitute for DIY."
I guess I disagree.
Without trying to sound like an elitist, my father taught me that doing this kind of work is not "brainy" work, but it is labor intensive and requires careful thought. With no offense meant (really!), it sounds like you are skipping the last part :)
Every book I have tells you to make sure header boards are true. Nailing schedules are often controlled by building code (though maybe not in this exact case, dunno where this closet is :P). Unless you are building a house from scratch, a framing nail gun is probably overkill, etc.
These things you call "learning mistakes" sound like "not being careful" to me. I see this often with software dev friends I helped. Because they are so used to throwing stuff out, they almost try to "incrementally" frame a window or whatever until they get one that works, rather than carefully think about where they are putting nails, measuring, marking, leveling, etc, before doing anything.
Remember that the contractors and handymen you watch have done this all a long time, and can probably do things like simply look at a frame and tell whether it's true with high accuracy.
They also don't need to think as much about how to put nails in.
Again, i'm really not trying to tell you "you are doing it all wrong", just offering an opinion :)
I think in the end, the best way to overcome it is to just run at it. The screw it, let's do it mentality really helps me kickstart physical projects. I look at where I am, where I need to be and do/buy whatever it takes.
1. Materials are cheap, how much did the roommate spend?
2. Laziness in code and physical is exactly the same psychological fuel: being bored doing always the same annoying task (eg remove the things to make room for the pizzas) is a strong incentive to find a hack to avoid the bore (add a contraption on the side of the table).
A former colleague was a great hacker, and he also did his own rollerblades, and built a part of his house.
I am some kind of software hacker too (daylong in python internals) and I did fix a car with a stone, I did elevated bed on two shelves, and currently I'm transforming a dead pot plant root into a nice piece of arte povera.
Another way for software and physical world hacking to be similar: in both cases, many people believe it to be hard, are afraid or somewhat restrained, but nearly all it takes is to just say to oneself "it's easy, let's try". While there are a few people with a brain that is no fit for fiddling with computers or screwdrivers, most of them who think they can't do it just never tried.
1. I've gone into hardware stores for small DIY tasks and parts/materials are not stuff you can buy with spare change. Tools and equipment are even more expensive.
2. Getting up and doing something physical for some of us takes a lot more effort than a mentally strenuous task.
Tools and equipment: It seems that the roommate did not use a lot of them. You can buy the best electronic screwdriver but you can also very often achieve the same result with a cheap screwdriver or even a kitchen knife.
For me digging deep into some code base, grepping the docs, reading some code in language I am not familiar with or that I dislike is exhausting, mentally and physically. I actually sweat a lot doing that, and it is the kind of sweat that stinks. Doing some woodwork is often less tiring, and the sweat it produces does not smell that bad.
> Tools and equipment: It seems that the roommate did not use a lot of them. You can buy the best electronic screwdriver but you can also very often achieve the same result with a cheap screwdriver or even a kitchen knife.
But the point is only that he only had one door. No room for trying it, breaking the door, and then trying again (your door is broken). Coding is the opposite: you get infinite retries.
> For me digging deep into some code base, grepping the docs, reading some code in language I am not familiar with or that I dislike is exhausting, mentally and physically. I actually sweat a lot doing that, and it is the kind of sweat that stinks. Doing some woodwork is often less tiring, and the sweat it produces does not smell that bad.
I envy you. I love everything on a computer (and never exhausting). Doing anything physical makes me completely miserable (possibly because I'm in terrible shape).
One door: sure that's a difference but not that significant. You can measure it and try in mentally in different positions. You have to think twice before sawing but actually in code you also have steps where thinking twice I'd required, eg choosing a framework, a data structure.
Shape: not sure it can be helpful but you could try to convince yourself that it's only in your head. I have seen very fat people doing physical work and enjoying it, maybe needed more frequent pauses, and but quite able to do anything except crawling under the table.
Materials are cheap, how much did the roommate spend?
First of all, the materials were "free" because they were already bought & paid for. Second of all the more important observation is that even though that first closet door was "free", he didn't have an infinite number of doors to mess up, throw out, and start from scratch.
In third world countries I am always so amazed at what people come up with when building things. When I set out to start a project it usually involves making a list, and then going to Lowes or Home Depot (hardware stores). People who don't have that luxury just repurpose other things, and usually always does the job for them. My friends in another country actually seem to enjoy their hack-together process very much.
My son is this way (I wouldn't call him genius, but his aptitude to seeing potential solutions is astounding.) It's being able to see a solution from existing pieces, requiring visualization and great spatial reasoning. I'm not sure it can be learned; there is something about it that's quite innate to a person.
I think the problem is that it is unlearned too easily. Being forced to modify your thinking to succeed in school or the workforce is what stifles this kind of creativity. I feel like I used to have gifts like that, but somehow lost it along the way
I would say that some of the spacial reasoning ability is innate to a person, and will determine how easy it is for the person to learn to solve physical problems. Past this, a lot of the ability comes from having seen similar concepts before and being able to create an elegant solution from them.
When I solve problems like this I typically get a vague sort of vision of what the final solution is going to look like in my head (possibly the innate part). Then I take all the little things I know about and slowly build up something that will perform the action I want. After which it becomes a task of optimization by combining and changing things until the final solution falls out (the experience part). When you have 2 or 3 people working on the same problem using this process some really special things often come out of it.
I'm not sure -- OP mentions the guy is a musician and specifically a pianist, so perhaps he just intrinsically has developed great spatial reasoning from learning and practicing with his piano for so long -- that along with him being from another country makes this make a lot more sense for me, although it's all still impressive.
The guy creativity is good, but sleeping/eating/working in the bed is a terrible idea. Moreover he is using a projector, meaning the needs to be in the dark...
it's amazing how limited we get as we have more things at our disposal. I remember coding basic as a kid and for hours i could come up with cool ideas and functioning programs. now all i think about is how to optimize and make things run faster by following codes already written by someone else! kudos to him..
This is a refreshing reminder to dig deeper. I'm always waiting for the right tool to come around to do the job (cheap hi-res 3d printing for example) but sometimes a good enough solution just might be sitting in front of you. Thanks for this!
I can see a scroll-bar but no text (javascript disabled here). What a naive way to design a website! I wouldn't be so snarky if this was a one-off instance. Sadly, this trend is catching up.
I don't see the connection between reading and scroll bars. Are you unable to scroll without a scroll bar (a possibility, but many keys work well too)?
For me they don't, not the arrow keys, not PgDn or PgUp, not Vimium compatible (j,k,g,d,u), and since no scrollbar to click only the scroll-wheel allowed me to see the rest of the article. (Chromium 30.0.1599.114 on Ubuntu 13.04)
I use Vimperator, not Vimium, but I had the same problem. The issue is the initial focus being on the static bar; if you 'tab' once to focus on the article, j/k works again. Alternatively, you can click the article to focus it.
Please don't do a serious website without a container div limiting the width of the reading area. Most people with laptops keep their browser windows maximized, and resizing the window just to read one article is a huge pain in the ass. I usually just decide not to bother. Otherwise that website's great.
Are you talking about the web browser or the web page here? Or maybe the OS/DE that makes it awkward to split the screen/size the window to reading width?
Or the laptop, with it's silly form factor?
But sure, everyone that publishes some text better make sure they account for every context that it might get viewed in.
In the spirit of offering solutions, here's some code you can use to add a 'Narrow' button to your browser:
I thought it was bizarre that you thought having every author of a webpage put some noise in their code was the right place to fix your technology stack.
It's not noise, it's presentation markup. That's what HTML/CSS is for. To manage the presentation of information. It's not that hard. Learn a little responsive CSS and have the div go away if the browser's width drops below, say, 600px.
Visual presentation is a hard problem, has been ever since the tele-type days. You're always going to need some "noise". I'm not saying you have to go full-hog with design bling, but you should at least learn enough about responsive CSS so that your site is usable across the three main types of screen it will be displayed on.
I would still argue that making the browser aware of the screen it is using (or perhaps, aware of the screen real estate it currently occupies and the text size preference of the user) is a better solution than adding a div to every serious web page.
Also, I'm pretty sure that (at least for simple pages) styling the body element will work just as well.
Why would that be any better? The only thing the page displaying in any browser needs to be aware of is how big the viewing window is, and the DPI. With those two pieces of information, you can have anything that runs in a browser present a useful interface.
That way content can handle all the edge cases that different screens can throw at them. And different browsers can handle things like text sizes the way they want to.
You don't want to have to make individual websites cater to individual screens or browsers. There's just too many of both. The interface between them needs to be a loose coupling.
A better way to say what I was getting at is that a web browser that finds itself with a silly window size might better serve the user by only using a portion of it for the viewport.
This way a page with no extra width styling still gets presented to the user in a sensible fashion. It's probably a looser coupling than insisting that every page anticipate and handle the screens it might be viewed on.
The browser shouldn't be dictating how the web works. It's the creator's job to manage the complexity of presentation, you can't just push that responsibility onto your tech stack. The domain and expected use cases for web apps is just too broad for any browser to be making decisions like this.
You don't need responsive CSS, all you need is max-width.
The (technically) ideal place to solve this is in your browser's user stylesheets (then you can have the page look however you like!), but that's a bad solution right now for obvious reasons (how many people even know that they exist?).
User stylesheets will always suck, because the pages you're depending on for your stylesheets to work is a concretion, not an abstraction. You're just going to have constant problems with the user CSS conflicting with the creator's styling.
The right way to do this would involve an evolution in the community where you could easily get the content you need in JSON format or similar. Then you can create your own presentation, or, more likely, subscribe to a site/service that collects user-created presenters.
A document mixes information with presentation. It's not data. Because it mixes information with presentation, you have to re-prepare it for each medium you intend to display it on.
HTML is a poor document format. If you store your document as HTML, then you also have to store the CSS along with it or it won't be a complete document. Unless you want to include the styling in the HTML file, a kludge which violates the Single Responsibility Principle.
There are plenty of document formats out there that don't have this issue, like PDF or RTF.
If you want your document to look more like data, then what you do is factor out all the atomic bits of information into values that you can then input into a database. Then write code to present it. Works well for structured documents like orders, invoices, or reports, less so for unstructured information like blog posts. For these, mixing presentation with information is unavoidable, just adding bold-face to a word means you'll need to store presentation information in your data. The "semantic web" is intended to address this.
> And after CSS was introduced, HTML was definitely not supposed to be presentational.
Presentation involves more than just style. CSS handles the style of web content, HTML handles the structure.
I'm familiar with the distinction between document and data. I'm talking about a site like a blog, where the document is the data. That was the original context of this conversation, IIRC.
HTML is emphatically not a poor document format, but it satisfies different requirements than PDF and RTF do. The weak connection between structure and what you call "style" (what I would call presentation) is a feature; it allows clients to modify the presentation to suit their needs. If I want a bigger font or higher contrast or a smaller column width, I'm able to do that because of the separation between structure and style.
But (as you rightly pointed out) this is a lot harder than it should be (and harder than it used to be). As a result, when an HTML document doesn't work for someone (due to its presentation) they have to complain to document creators instead of merely configuring their client (once) to suit their needs. This sucks.
> But (as you rightly pointed out) this is a lot harder than it should be (and harder than it used to be).
It's hard because doing this is moving in the wrong direction concerning the intended abstractions.
As I said earlier, a document combines unstructured information with presentation, and you have to re-do the document every time the presentational logic changes. This is necessary because the information in the document is unstructured, it's not like an order form.
Because you cannot predict what form unstructured information will take, the presentational logic is necessarily strongly coupled with the information. That's why it's hard to do what you want. You can pop open Dev Tools and manually do it, but you can't write a program that will take _all blog posts_ and restructure them the way you want to, because _all blog posts_ is impossible to reason about.
No amount of evolution to the HTML or CSS standards will work out this particular bit of complexity. If you could standardize a blog post, then you could write a program to do it. But it would only work on posts that meet the standard.
Say you made it so every blog CMS out there stored the text in the DB in Markdown format and provided an API so you could get at the Markdown. Then you could do what you say, provide your own styling. What this would be doing is introducing a separation of concerns. You push most of structure out of the data, and divide up styling duties between a base level (Markdown) and an upper level. (whatever you're using to display it) You may not even need the API if the CMS doesn't screw around too much with the presentation by putting, say, ads, in the middle of the content. Then you could screen scrape and convert the generated HTML back into Markdown, but again, this is the wrong way to go, (depending on concretion rather than abstraction) and prone to breakage. You really need the API layer to do this properly.
But you can't hope that one day HTML and CSS will make sense again like the old days and that user-styling will work again. It only worked before in the very early days of the web because everything was super simple and people could live with the edge cases that cropped up, not because the underlying domain changed. That solution was always brittle, and it broke the second people wanted greater flexibility in presentation.
Because you always want to depend on abstraction, not concretion. If you have a whole bunch of data, and you know that all the data has 7 fields and none of the entries in field 3 are null, then that's much easier to work with if you don't know how many fields are in your data at all, or if some of the data has 9 fields and some of it has 3. If you have this situation, then you have to take an extra step to clean your data before you can reason about it properly.
The HTML you get when you go to a web page is anything but an abstraction of a data type. If you want it to get that way, now we're back to telling the whole web how to make web pages.
> The HTML you get when you go to a web page is anything but an abstraction of a data type.
You don't think that "this is an article", "this is a paragraph", "this is a link", "this text should be emphasized" are abstractions? And how is Markdown different, when it describes exactly the same elements of a document?
> now we're back to telling the whole web how to make web pages.
Telling people how to make web pages isn't a problem - that's what the HTML standard is. Depending on the whole web to make their pages suit your individual needs is a problem.
> You don't think that "this is an article", "this is a paragraph", "this is a link", "this text should be emphasized" is an abstraction?
It's not. There's many different ways to do this with HTML/CSS. You can use bold tags or spans. If you use spans, then you have to understand the class and the CSS before you can tell that this text is supposed to be bold-faced rather than colored differently.
Links can be specified in the HTML or added in with jQuery. An article can be described with a semantic HTML tag or a div with a class. If it's the latter, you've got to parse the class and figure out what it means. If you're lucky it will be 'article'. But you probably won't be.
HTML cannot be looked at as a data type. Markdown specifies one and only one way to do all of the above. That's a proper abstraction.
> Telling people how to make web pages isn't a problem - that's what the HTML standard is.
You can announce a set of 'best practices', but that's not a standard. A standard is an abstraction that you can rely on other people using because otherwise the vast majority of software won't work with it. Best practices cannot be relied on, you follow them for your own benefit, not others.
The HTML standard is insufficient for this kind of use. And it will remain this way because HTML isn't intended the way you seem to think it is.
> If you're lucky it will be 'article'. But you probably won't be.
This situation can be improved (and is being improved). If we treat HTML as nothing but a display language, then it will become one - and if that's what you want, then you should just be using PDF, PNG or SWF.
> And it will remain this way because HTML isn't intended the way you seem to think it is.
I guess we've reached the root of our disagreement. It's exactly how it was intended to be used historically, it's how it is still used for the most part (with webapps being a notable exception), and I think it's the best way to use it going forward.
Is there some third way? Occasionally I really want it that wide, and if there's a div there's no way (short of firebug or grease monkey) to get it. At the same time, as someone who quite frequently has windows maximized, I feel some of your pain - though "ctrl-f S <read> ctrl-f Q" isn't exactly a "huge pain in the ass".
That is far more impressive than my one attempt at modifying my bed, which no one would attach the word "genius" to...the most likely word I would have earned was "special".
I was living in a small rectangular room at Caltech, with the door on one of the short sides and a window and radiator on the other short side. My bed was a rectangular framework that the mattress sat on top of. The long sides of the bed were parallel to the long sides of the room, said orientation being forced by the narrowness of the room.
The pillow side of the bed was toward the window and radiator. I decided I'd rather sleep with my feet on that side and my head on the other side.
One afternoon, I set about reorienting the bed to accomplish this. Because of the narrowness of the room, both horizontally and vertically, it was quite a challenge to flip the bed around, but after quite a struggle I accomplished it. While I was doing this, a small crowd had gathered to watch (but not help...the bastards).
After I finished, the spectators pointed out that the bed frame and mattress were symmetrical, and the sleeping orientation was determined entirely by what side you tucked the sheets under and where you put the pillow. Flipping the sleeping orientation would have taken a normal person 10 seconds.
A buddy of mine lived in one of those extra cheap campus dorms where each room is a mirror image of itself with a bed and desk against each wall with a bookshelf bolted to the wall above. I was hanging out on the evening when he decided to take down one of the bookshelves.
I never got a chance to ask quite why he was unbolting the thing from the wall, because no sooner had he removed the 3rd bolt than there was this enormulous crashing disaster in the room next door.
Sure enough, glancing across at the opposite wall, the bookshelf on that side had a washer and a nut threaded onto the end of a bolt.
Wow that room layout sounds a lot like my dorm, except we had two bookshelves, and they were not bolted through the wall like that, some people could remove them and put them vertically to have a vertical cabinet.
These 'Doh' situations happen to everyone. I once carried large heavy wheel for about 50 meters before I realized I could just roll it on the ground :)
Regarding to hacking around I think almost everyone could do something if he just stop and try to think what could be done. We often don't notice opportunities right before our noses because we simple don't focus on trying to do something with it. I myself enjoy that type of hacking. Recently we had some reconstruction at home and we had some leftover materials in garbage pile ready to be thrown away. So I grabbed one leftover ceramic floor tile, couple of stair wooden balusters and some thin plywood. I sawed each baluster in half (they had central symmetry), screwed them to plywood on both sides, glued ceramic tile to plywood from one side and small pillars to the other side and then painted wood. Couple of hours of work and got myself a pretty slick looking side table, which I needed at the time :)
The only thing I bought were small silver pillars which cost couple of dollars.
Bender's picture is also some kind of hacking, I printed picture at the local photo workshop and made the frame from a very cheap plastic ceiling plinth.
My self-esteem is absolutely crushed, every time I encounter one of those everyday puzzles, which includes fitting a very tight cover on my mattress.
I wish I could reduce it to some algorithmic problem, but by the end of the day, I look like someone wrestling an alligator, as I struggle to put it on.
Start on the far end and pull the sheets towards you. That is, if your bed is next to a wall or two (as usual), start with the corners next to it, this way you never have to kneel over the sheets. If possible you can also move the bed and walk around.
This one took me a while to figure out, but was proud when I did. :)
We put hammocks in our dorm room to free up the beds for construction materials. Except we didn't count on the steel studs, which when were both in our hammocks caused one wall to bow in ominously. The whole lie in the hammocks with our girlfriends thing was clearly not going to work. :-)
When I relocated to work for my current employer, they put me on a temporary house which had three floors. When I arrived from the airport with a huge suitcase, I almost died of exhaustion taking it upstairs (it was really large and heavy!). Only then I realized I could have left the suitcase downstairs and taken my stuff upstairs in smaller batches...
Doh!
On a related note, I wish my wife was with me at the time. I often tell her she's the smart half of the couple, since I repeatedly have these "Doh!" moments but when she's around she is able to correct me and show me there's a simpler way :)
Yeah the dude is smart and creative. But for all you HN fellows who find this so impressive, you must not have much creativity of your own. Or more likely I suspect you've never had the freedom to experiment like this.
Some responses in this thread surprise me, I thought the mindset exposed in this article was something most hackers shared. Therefore, after reading the post, I expected a bunch of mildly negative comments of people who built a lot of awesome things in their spare time. Well, I was wrong.
Anecdotal but surprising, my fellow musician friends are more prone to what I believe to be the hacker thinking than most of the software programmers I work with. Maybe it is because of some unfortunate psychological barrier, or the result of a strong focus on computer related things and discard for the rest, I honestly don't know.
Anyways, what this roommate did is super cool, and I'd suggest everyone here to start hacking outside of their comfort zone, it can be very rewarding for some. Building things feels great, and being able to apply your hacker thinking to various things is a very useful skill to have.
I had pretty serious musical training that lasted for a few years. Anyways, my teachers were crazy imaginative. They would also build stuff from what looked like scraps - insulated and strengthened jacks, book shelves, studio monitor stands, etc, etc.
I've never had serious musical training, but I've spent a lot of time picking tunes with old folkies. A lot of those guys are absolutely the same when it comes to this sort of creativity, and I picked up a lot of advice that I like to think has stuck with me ever since. I remember I was nervous as hell when I'd just started heading along to jams - here was me, having learned a bit about scales and a few chords, yet wondering how I could ever contribute to the wonderful sounds this group was creating. It was an old gentleman in his 70s who just turned around, saw me sat there overwhelmed, trying to figure out what was going on, and said "We've got seven notes in a scale, and most of these tunes'll barely use half of 'em!".
Music, at its heart, is the ultimate in making do with what you have - I just think that folkies are more likely to admit it!
Before the days of time-sucking TVs and you-need-this prolific advertising and anything-anywhere-now product availability, people spent a lot of their time doing what they could with what they had. Radios out of scrap wire & fragmentary parts, goofy vehicles from whatever rods & panels available, toys from broken widgets, etc. "Lifehacking" was the norm. "Recycling" wasn't a different-colored trash bin, it was repurposing every part of everything conceivable; even food waste was turned into quality dirt. When a plane crashed near my great-grandparent's farm, they hauled the whole thing back to the farm and used every part of it. Partly out of frugal economic necessity, partly out of limited product availability, partly out of sheer raging boredom.
It's not so much that your teachers were crazy imaginative, it's that most people today are so freaking lazy and rich (while claiming overwork & poverty).
I've noticed the same thing in musician friends of mine, and I think it really isn't so much that their mindset is different from 'us' hackers, but rather that we spend so much time on virtual stuff that we don't learn to apply our mindset to the real world.
In fact, a lot of us probably under-perform when it comes to real-world hacking because we're so caught in the virtual. I know that's true for me.
This did give me a bit of a new perspective on things, and makes me wonder if I should start some more real-world hacking...
A couple of the most innovative hackers I know are also musicians. A big motivation is simply money. They've embraced the fact that they'll always be poor. Hacking is essential to build & maintain the tools they need for life and for work, as well as a great source of cheap entertainment.
I think you're right, money (or more, the lack thereof) must be a good trigger for the hacking brain to get turned on. Come to think of it, that's probably how I got started as a kid.
I thought the mindset exposed in this article was something most hackers shared
That's what I think as well, and for me this mindset is a defining characteristic of hackers. Most of programmers nowadays are not hackers. They used to be, but then programming went mainstream and attracted people without the hacker mindset.
Also the term hacker got terribly diluted recently. Now everyone and their dog is a hacker just because they know that JavaScript is something that is used 'on the interwebz' (cf. "growth hacking"). I guess we need a new term for people like OP's roommate.
Not to take away the intelligence of people but a hacker is someone who excels in situations as this - Limited time, limited resources/cheapness to spend money, Have objects X, Need functions Y.
That takes a hacker. Everything else is just a builder (be it building code, or cabinets, or robots). The core ideology of being a hacker is seeing beyond the normal functionality of the item like this roommate has seen. He looked at the wardrobe and saw a sliding table. That is hacking.
They absolutely are. But in normal conversation when you speak to people about this, they'll most probably say "Wow, that's pretty smart man, I wouldn't have thought of using a pipe as a sound carrier" (or something like that).
My brother is very much the same. He's about to turn 14 and can make anything, out of almost anything. Both of my Grandfathers shared the same aptitude for this.
As a developer I feel I can apply these skills, but to code, whereas they're physically able to see an object or an end result.
178 comments
[ 3.9 ms ] story [ 214 ms ] threadSome other guy said design is editing: it's about removing all the ugliness so that only beauty remains.
Unfortunately, I think my developer mindset actually makes physical hacking a lot harder due to 2 phenomena:
1. Code is cheap. Materials are not. I'm used to being able to churn out additional code with basically no cost to get things done, not to repurposing existing code (this is different from refactoring to abstractions).
2. Laziness is a quality in software development, but a major obstacle in physical development. I'll quickly abandon physical projects because I can't find an optimally efficient hack to finish things in minimal time.
I'm wasting wood! OMG! But I've made progress. Watching contractors has helped. I was astonished how much they waste, treat things as disposable. My father (a hardware guy) certainly would not have approved.
I'm framing a new closet with bypass sliding doors. I really have no idea what I'm doing. I knocked apart the first two attempts and hope the third works better. And I'm now okay with it. It's been kinda fun.
While software can't be perfect, it has to be as flawless as possible. Code isn't cheap, it takes time. Who knows what else you could've built/made/learnt instead of fixing something cuz it costs "nothing"
That's an absolutely terrible approach to software development. You can test a program as many times as you want before releasing it, but there's no equivalent iterative process for making a house.
If you develop with that attitude, you'll never get anything of real value done. After all, "le mieux est l'ennemi du bien."
An algorithm has mathematical underpinnings and can be created entirely on paper first. Turning ideas into applications however is drastically enhanced by prototyping extensively.
This is pretty much why real engineers scoff at the title 'software engineer.'
Unless they program in Ada.
It was probably a root barrier which was put there for the sole purpose of stopping the trees from growing and destroying your house.
Framing lumber is cheap, but that's no excuse to waste so much. Contractors do it because they are charging other people for materials :)
In your case, if you are going to be remodeling your house and doing structural carpentry, i'd recommend "Renovation 4th edition" by Michael Litchfield as a starter book.
Also if you start doing something with more expensive lumber, like say, very high end woodworking, you will see nobody treats stuff as disposable.
I've read the books, watched the videos, read the codes, helped my handyman friends. There's no substitute for DIY.
For the closet, I make a lot of little "learning opportunity" mistakes. I didn't make sure one of the header boards was truly true. I put 3-1/4 inches nails clean thru. Lots of trial and error with my spiffy new nail gun. Etc.
As for the software, I must be doing that wrong too. I'm always rewriting my own stuff.
I guess I disagree. Without trying to sound like an elitist, my father taught me that doing this kind of work is not "brainy" work, but it is labor intensive and requires careful thought. With no offense meant (really!), it sounds like you are skipping the last part :)
Every book I have tells you to make sure header boards are true. Nailing schedules are often controlled by building code (though maybe not in this exact case, dunno where this closet is :P). Unless you are building a house from scratch, a framing nail gun is probably overkill, etc.
These things you call "learning mistakes" sound like "not being careful" to me. I see this often with software dev friends I helped. Because they are so used to throwing stuff out, they almost try to "incrementally" frame a window or whatever until they get one that works, rather than carefully think about where they are putting nails, measuring, marking, leveling, etc, before doing anything.
Remember that the contractors and handymen you watch have done this all a long time, and can probably do things like simply look at a frame and tell whether it's true with high accuracy. They also don't need to think as much about how to put nails in.
Again, i'm really not trying to tell you "you are doing it all wrong", just offering an opinion :)
1. Materials are cheap, how much did the roommate spend?
2. Laziness in code and physical is exactly the same psychological fuel: being bored doing always the same annoying task (eg remove the things to make room for the pizzas) is a strong incentive to find a hack to avoid the bore (add a contraption on the side of the table).
A former colleague was a great hacker, and he also did his own rollerblades, and built a part of his house.
I am some kind of software hacker too (daylong in python internals) and I did fix a car with a stone, I did elevated bed on two shelves, and currently I'm transforming a dead pot plant root into a nice piece of arte povera.
Another way for software and physical world hacking to be similar: in both cases, many people believe it to be hard, are afraid or somewhat restrained, but nearly all it takes is to just say to oneself "it's easy, let's try". While there are a few people with a brain that is no fit for fiddling with computers or screwdrivers, most of them who think they can't do it just never tried.
1. I've gone into hardware stores for small DIY tasks and parts/materials are not stuff you can buy with spare change. Tools and equipment are even more expensive.
2. Getting up and doing something physical for some of us takes a lot more effort than a mentally strenuous task.
For me digging deep into some code base, grepping the docs, reading some code in language I am not familiar with or that I dislike is exhausting, mentally and physically. I actually sweat a lot doing that, and it is the kind of sweat that stinks. Doing some woodwork is often less tiring, and the sweat it produces does not smell that bad.
But the point is only that he only had one door. No room for trying it, breaking the door, and then trying again (your door is broken). Coding is the opposite: you get infinite retries.
> For me digging deep into some code base, grepping the docs, reading some code in language I am not familiar with or that I dislike is exhausting, mentally and physically. I actually sweat a lot doing that, and it is the kind of sweat that stinks. Doing some woodwork is often less tiring, and the sweat it produces does not smell that bad.
I envy you. I love everything on a computer (and never exhausting). Doing anything physical makes me completely miserable (possibly because I'm in terrible shape).
Shape: not sure it can be helpful but you could try to convince yourself that it's only in your head. I have seen very fat people doing physical work and enjoying it, maybe needed more frequent pauses, and but quite able to do anything except crawling under the table.
First of all, the materials were "free" because they were already bought & paid for. Second of all the more important observation is that even though that first closet door was "free", he didn't have an infinite number of doors to mess up, throw out, and start from scratch.
Not sure where he got his ideas from. His front door could be turned into a cash register + counter + door at the same time.
The store was full of furniture hacks.
You're right about the environment. Creativity often isn't well-aligned with traditional learning patterns.
At least that is how it works for me most of the time. Although I guess I do take direct inspiration from the things themselves sometimes.
When I solve problems like this I typically get a vague sort of vision of what the final solution is going to look like in my head (possibly the innate part). Then I take all the little things I know about and slowly build up something that will perform the action I want. After which it becomes a task of optimization by combining and changing things until the final solution falls out (the experience part). When you have 2 or 3 people working on the same problem using this process some really special things often come out of it.
You see some of this sort of thing from the blue collar part of society in the US - "yankee ingenuity" is what it sometimes gets called here.
This is an essay by Tom Wolfe about Noyce and Intel that has similar overtones:
http://www.stanford.edu/class/e140/e140a/content/noyce.html
Edit: Cut down the snarkiness.
The OP's openness to criticism is appreciated.
For me they don't, not the arrow keys, not PgDn or PgUp, not Vimium compatible (j,k,g,d,u), and since no scrollbar to click only the scroll-wheel allowed me to see the rest of the article. (Chromium 30.0.1599.114 on Ubuntu 13.04)
(Oh, I forgot that the web browser is not an application, but a platform and an OS in its own right, and has replaced the native OS. Silly me.)
Or the laptop, with it's silly form factor?
But sure, everyone that publishes some text better make sure they account for every context that it might get viewed in.
In the spirit of offering solutions, here's some code you can use to add a 'Narrow' button to your browser:
https://gist.github.com/maxerickson/7771860
I thought it was bizarre that you thought having every author of a webpage put some noise in their code was the right place to fix your technology stack.
Visual presentation is a hard problem, has been ever since the tele-type days. You're always going to need some "noise". I'm not saying you have to go full-hog with design bling, but you should at least learn enough about responsive CSS so that your site is usable across the three main types of screen it will be displayed on.
Also, I'm pretty sure that (at least for simple pages) styling the body element will work just as well.
That way content can handle all the edge cases that different screens can throw at them. And different browsers can handle things like text sizes the way they want to.
You don't want to have to make individual websites cater to individual screens or browsers. There's just too many of both. The interface between them needs to be a loose coupling.
This way a page with no extra width styling still gets presented to the user in a sensible fashion. It's probably a looser coupling than insisting that every page anticipate and handle the screens it might be viewed on.
The (technically) ideal place to solve this is in your browser's user stylesheets (then you can have the page look however you like!), but that's a bad solution right now for obvious reasons (how many people even know that they exist?).
The right way to do this would involve an evolution in the community where you could easily get the content you need in JSON format or similar. Then you can create your own presentation, or, more likely, subscribe to a site/service that collects user-created presenters.
When user stylesheets were conceived this is what HTML was.
You do if your data is a document.
And after CSS was introduced, HTML was definitely not supposed to be presentational.
A document mixes information with presentation. It's not data. Because it mixes information with presentation, you have to re-prepare it for each medium you intend to display it on.
HTML is a poor document format. If you store your document as HTML, then you also have to store the CSS along with it or it won't be a complete document. Unless you want to include the styling in the HTML file, a kludge which violates the Single Responsibility Principle.
There are plenty of document formats out there that don't have this issue, like PDF or RTF.
If you want your document to look more like data, then what you do is factor out all the atomic bits of information into values that you can then input into a database. Then write code to present it. Works well for structured documents like orders, invoices, or reports, less so for unstructured information like blog posts. For these, mixing presentation with information is unavoidable, just adding bold-face to a word means you'll need to store presentation information in your data. The "semantic web" is intended to address this.
> And after CSS was introduced, HTML was definitely not supposed to be presentational.
Presentation involves more than just style. CSS handles the style of web content, HTML handles the structure.
HTML is emphatically not a poor document format, but it satisfies different requirements than PDF and RTF do. The weak connection between structure and what you call "style" (what I would call presentation) is a feature; it allows clients to modify the presentation to suit their needs. If I want a bigger font or higher contrast or a smaller column width, I'm able to do that because of the separation between structure and style.
But (as you rightly pointed out) this is a lot harder than it should be (and harder than it used to be). As a result, when an HTML document doesn't work for someone (due to its presentation) they have to complain to document creators instead of merely configuring their client (once) to suit their needs. This sucks.
It's hard because doing this is moving in the wrong direction concerning the intended abstractions.
As I said earlier, a document combines unstructured information with presentation, and you have to re-do the document every time the presentational logic changes. This is necessary because the information in the document is unstructured, it's not like an order form.
Because you cannot predict what form unstructured information will take, the presentational logic is necessarily strongly coupled with the information. That's why it's hard to do what you want. You can pop open Dev Tools and manually do it, but you can't write a program that will take _all blog posts_ and restructure them the way you want to, because _all blog posts_ is impossible to reason about.
No amount of evolution to the HTML or CSS standards will work out this particular bit of complexity. If you could standardize a blog post, then you could write a program to do it. But it would only work on posts that meet the standard.
Say you made it so every blog CMS out there stored the text in the DB in Markdown format and provided an API so you could get at the Markdown. Then you could do what you say, provide your own styling. What this would be doing is introducing a separation of concerns. You push most of structure out of the data, and divide up styling duties between a base level (Markdown) and an upper level. (whatever you're using to display it) You may not even need the API if the CMS doesn't screw around too much with the presentation by putting, say, ads, in the middle of the content. Then you could screen scrape and convert the generated HTML back into Markdown, but again, this is the wrong way to go, (depending on concretion rather than abstraction) and prone to breakage. You really need the API layer to do this properly.
But you can't hope that one day HTML and CSS will make sense again like the old days and that user-styling will work again. It only worked before in the very early days of the web because everything was super simple and people could live with the edge cases that cropped up, not because the underlying domain changed. That solution was always brittle, and it broke the second people wanted greater flexibility in presentation.
This is exactly what I'm saying.
> Then you could screen scrape and convert the generated HTML back into Markdown,
Why do you want the Markdown at all?
Because you always want to depend on abstraction, not concretion. If you have a whole bunch of data, and you know that all the data has 7 fields and none of the entries in field 3 are null, then that's much easier to work with if you don't know how many fields are in your data at all, or if some of the data has 9 fields and some of it has 3. If you have this situation, then you have to take an extra step to clean your data before you can reason about it properly.
The HTML you get when you go to a web page is anything but an abstraction of a data type. If you want it to get that way, now we're back to telling the whole web how to make web pages.
You don't think that "this is an article", "this is a paragraph", "this is a link", "this text should be emphasized" are abstractions? And how is Markdown different, when it describes exactly the same elements of a document?
> now we're back to telling the whole web how to make web pages.
Telling people how to make web pages isn't a problem - that's what the HTML standard is. Depending on the whole web to make their pages suit your individual needs is a problem.
It's not. There's many different ways to do this with HTML/CSS. You can use bold tags or spans. If you use spans, then you have to understand the class and the CSS before you can tell that this text is supposed to be bold-faced rather than colored differently.
Links can be specified in the HTML or added in with jQuery. An article can be described with a semantic HTML tag or a div with a class. If it's the latter, you've got to parse the class and figure out what it means. If you're lucky it will be 'article'. But you probably won't be.
HTML cannot be looked at as a data type. Markdown specifies one and only one way to do all of the above. That's a proper abstraction.
> Telling people how to make web pages isn't a problem - that's what the HTML standard is.
You can announce a set of 'best practices', but that's not a standard. A standard is an abstraction that you can rely on other people using because otherwise the vast majority of software won't work with it. Best practices cannot be relied on, you follow them for your own benefit, not others.
The HTML standard is insufficient for this kind of use. And it will remain this way because HTML isn't intended the way you seem to think it is.
This situation can be improved (and is being improved). If we treat HTML as nothing but a display language, then it will become one - and if that's what you want, then you should just be using PDF, PNG or SWF.
> And it will remain this way because HTML isn't intended the way you seem to think it is.
I guess we've reached the root of our disagreement. It's exactly how it was intended to be used historically, it's how it is still used for the most part (with webapps being a notable exception), and I think it's the best way to use it going forward.
I was living in a small rectangular room at Caltech, with the door on one of the short sides and a window and radiator on the other short side. My bed was a rectangular framework that the mattress sat on top of. The long sides of the bed were parallel to the long sides of the room, said orientation being forced by the narrowness of the room.
The pillow side of the bed was toward the window and radiator. I decided I'd rather sleep with my feet on that side and my head on the other side.
One afternoon, I set about reorienting the bed to accomplish this. Because of the narrowness of the room, both horizontally and vertically, it was quite a challenge to flip the bed around, but after quite a struggle I accomplished it. While I was doing this, a small crowd had gathered to watch (but not help...the bastards).
After I finished, the spectators pointed out that the bed frame and mattress were symmetrical, and the sleeping orientation was determined entirely by what side you tucked the sheets under and where you put the pillow. Flipping the sleeping orientation would have taken a normal person 10 seconds.
Doh!
A buddy of mine lived in one of those extra cheap campus dorms where each room is a mirror image of itself with a bed and desk against each wall with a bookshelf bolted to the wall above. I was hanging out on the evening when he decided to take down one of the bookshelves.
I never got a chance to ask quite why he was unbolting the thing from the wall, because no sooner had he removed the 3rd bolt than there was this enormulous crashing disaster in the room next door.
Sure enough, glancing across at the opposite wall, the bookshelf on that side had a washer and a nut threaded onto the end of a bolt.
These 'Doh' situations happen to everyone. I once carried large heavy wheel for about 50 meters before I realized I could just roll it on the ground :)
Regarding to hacking around I think almost everyone could do something if he just stop and try to think what could be done. We often don't notice opportunities right before our noses because we simple don't focus on trying to do something with it. I myself enjoy that type of hacking. Recently we had some reconstruction at home and we had some leftover materials in garbage pile ready to be thrown away. So I grabbed one leftover ceramic floor tile, couple of stair wooden balusters and some thin plywood. I sawed each baluster in half (they had central symmetry), screwed them to plywood on both sides, glued ceramic tile to plywood from one side and small pillars to the other side and then painted wood. Couple of hours of work and got myself a pretty slick looking side table, which I needed at the time :) The only thing I bought were small silver pillars which cost couple of dollars.
Here's photo: http://i.imgur.com/6OsLDPu.jpg
Bender's picture is also some kind of hacking, I printed picture at the local photo workshop and made the frame from a very cheap plastic ceiling plinth.
I wish I could reduce it to some algorithmic problem, but by the end of the day, I look like someone wrestling an alligator, as I struggle to put it on.
This one took me a while to figure out, but was proud when I did. :)
Doh!
On a related note, I wish my wife was with me at the time. I often tell her she's the smart half of the couple, since I repeatedly have these "Doh!" moments but when she's around she is able to correct me and show me there's a simpler way :)
Anecdotal but surprising, my fellow musician friends are more prone to what I believe to be the hacker thinking than most of the software programmers I work with. Maybe it is because of some unfortunate psychological barrier, or the result of a strong focus on computer related things and discard for the rest, I honestly don't know.
Anyways, what this roommate did is super cool, and I'd suggest everyone here to start hacking outside of their comfort zone, it can be very rewarding for some. Building things feels great, and being able to apply your hacker thinking to various things is a very useful skill to have.
I wonder what makes them tick like this!
Music, at its heart, is the ultimate in making do with what you have - I just think that folkies are more likely to admit it!
It's not so much that your teachers were crazy imaginative, it's that most people today are so freaking lazy and rich (while claiming overwork & poverty).
In fact, a lot of us probably under-perform when it comes to real-world hacking because we're so caught in the virtual. I know that's true for me.
This did give me a bit of a new perspective on things, and makes me wonder if I should start some more real-world hacking...
That's what I think as well, and for me this mindset is a defining characteristic of hackers. Most of programmers nowadays are not hackers. They used to be, but then programming went mainstream and attracted people without the hacker mindset.
Also the term hacker got terribly diluted recently. Now everyone and their dog is a hacker just because they know that JavaScript is something that is used 'on the interwebz' (cf. "growth hacking"). I guess we need a new term for people like OP's roommate.
That takes a hacker. Everything else is just a builder (be it building code, or cabinets, or robots). The core ideology of being a hacker is seeing beyond the normal functionality of the item like this roommate has seen. He looked at the wardrobe and saw a sliding table. That is hacking.
But did he extend your bed to make you happy, or to score those free extra parts?
I suppose I will have to go to my grave never knowing for sure.
Although it looks like your bed is a little saggy, right in the lumbar...
As a developer I feel I can apply these skills, but to code, whereas they're physically able to see an object or an end result.
I wish I could!