Before giving my answer I want to clarify that I do consider "hackers" to be developers, but unlike the previous question, with "hackers" I refer to developers in startups - people who build MVP's fast, getting the product to customers before running out of money. Of course, this would be valid for all types of engineering (not only web or even only software). Also, I must say that I am not a "hacker" and this simply is what I found interesting and useful while working on a recent project, together, with people having the hacker mindset and skills.

These few guidelines might not be the most useful thing if you don't want to go out of the comfort of working for stable, already-successful companies. But if you want to try and work in a startup (or you want to build a product), this is a short list of things, I am sure you will appreciate in time.

So here it goes...

1. If you can't "fool" yourself into thinking you will finish The New Project in a weekend, then you need to sit down and rethink carefully, if you should start it at all. Otherwise, you might very well have a year's worth of work ahead of you. There isn't a serious product you can complete in a weekend's time, but there is an iteration of a serious product you "might" be able to complete in 48h, such that will be buggy, only doing a single thing essential for your idea, but ready to test with potential customers. We (humans) are not as good, on estimating work, as we like to think we are. Actually, if you can see the possibility of getting the first iteration of a product done in 48h, it still might take 4 weeks. That's OK - it will not take a year, right?

2. Get things done. There was a post recently, I think it was by Sam Altman, the current president of YCombinator (probably the most famous startup incubator), who said something along these lines - After YC is over, because the peer pressure isn't there anymore, many startups don't work as hard and get on the spiral of doing 'fake work'. Fake work is both easier and more fun than real work. If your experience is coming from working for well-established and stable companies, this is something you might be struggling with. I don't like the term "fake work" and I honestly don't think he meant "fake" in the literal sense of the word. But anything that isn't the highest priority of the product and company, right now, is probably what he called fake work. These refactorings that will make our code-base shine, making software architects go "Wow!", while your customers wait for fixes or the business waits for critical features to get that revenue going, is bad prioritizing. The reason many people don't actually understand the importance of this is very simple, actually - many established companies don't have these problems. When all the core features are in place, the company is getting a good revenue and sales are growing, then it's time to fix, clean, build new features (in order of priority). But the people that got that product to reach such momentum, needed to prioritize very successfully and never do "fake work".

3. Sell first, build later. Building something cool that no one will see or use is worthless. Go out there and test the idea, before you even start building. This is something I've stupidly done, myself, and is something I will never repeat again. Even if you don't actually charge money before you build it - talk to people, build toys, pivot reasonably (not to be too far away from what made you passionate about solving a problem, but not before reaching a problem you are sure your solution is truly worth it) and test the demand for your products or features in advance. And if things don't work, you haven't invested so much to be more than 1st degree "devastated". :) There is no way to easily let go of ideas and products you believe in, but it's definitely easier to do it a month in, than, say, after a year.

4. Don't look down on hackers, to be a hacker is a skill, not lack of one. I have, in my own experience, fooled myself I can do things fast, the way hackers in startups do, without lifting a finger and changing anything in my approach. "Not writing tests, building things that will work no matter how exactly are they designed, making unscalable one-time solutions, I can do that. This is an easy way.". Boy, was I wrong... If you have years of TDD/BDD development under your belt, you are in for a big surprise - switching off an instinct is not an easy thing to do. And not only that, you need to be able to deal with the stress of developing things that are prototype-like under the hood, but are used in the real world and can break at any time, could be hard to fix and simply couldn't be scaled in many cases. I am not in any way sarcastic, this is something that startups currently need to do, in order to survive (read "succeed"). "We don't have time to build a few things Great, we have the time to build many things OK. Once we get to Series A, or even B, we will hire some smart kids to get into the code base and clean it up." This is what I've heard from founders.

So, these are things that many developers, especially people working in stable and already successful companies, don't necessarily know or even think about. But if you want to be on the forefront of technology, I believe you do need to learn how to be a "hacker".