Too scared to write a line of code - <AUTHOR> https://medium.com/i-m-h-o/eef96ea6f4cb?imm_mid=0a9102&cmp=em-velocity-newsletters-vl-save20-20130523-direct <comment><USER2> This is really kind of the whole idea behind the "red, green, refactor" mantra. The point isn't to write perfect code right out of the gate, it's to write _working_ code. Once the test is green, then you can refactor as necessary with the confidence that you aren't going to accidentally break things (as the test will backstop you).

Ironically, I think this is something that affects seasoned programmers more than new ones; the more you know about the trade, the more voices you have saying "no, that's wrong! Don't do that!", which can freeze progress. The way I combat it is by writing down pseudocode in my source code - literally just english, non-compiling pseudocode - which I then "refactor" into working code (thus the first "green" is "it parses"). By making step 0 the expression of the idea rather "writing the fist line of code", I can get right into the process rather than getting hung up on the "how".

<comment><USER3> Also kind of related - programming by "wishful thinking". You first lay out the flow of the program as calls to high level functions which don't yet exist, and then go back and fill in the functions as you can. The first few SICP video lectures are all about this style, and I found the idea simple but very useful to avoid trying to hold too much of a problem in your head at once.

<comment><USER2> Yes, exactly. By writing pseudocode, I end up writing business code rather than implementation code, which inherently assumes the a high-level interface to the nitty-gritty details. This leads to an approach where the idea is expressed at a high level first, rather than getting stuck in the implementation details of some small piece of the problem.

<comment><USER4> It's kind of "breadth-first search" on software development, while the classic approach is more "depth-first search".

On the other hand, it is also important to quickly get into the state of a running program, because only that allows for iterative development where you can catch bugs shortly after you wrote them, rather than having tons of bugs after weeks of (not sufficiently tested) work.

</comment></comment></comment></comment><comment><USER5> I program the way that I imagine I would sculpt. If I had to sculpt a head, I wouldn't start by sculpting the perfect ear, and then sculpting the perfect eye, etc, because who knows what will happen. Maybe in the course of sculpting the eye, I need to move the ear, and then all that work goes out of the door.

Instead, I would sculpt the entire piece of art roughly, almost unrecognizably, and then target large parts of the sculpture. Details like ears and eyes might even never get done, depending on how the requirements change for the sculpture.

I always approach writing software the same way, so the first iteration is just a hardcoded piece of software that just shows me that it will actually work, and then I iterate and start smoothing out all of the sharp edges, of which there are a ton.

</comment><comment><USER6> People interpret "just do it" as practical advice to write good code, but really it's practical advice to get code from people who won't otherwise write anything. Good code comes from both will and knowledge. When you don't have knowledge, will alone will do.

"Just do it" is the best advice for stuck people - you tell them to just start doing the thing, not worry about details, and eventually you'll do it right. This is good advice for a business guy who's pin-wheeling ideas in his head, a programmer with no product sense, or anyone else who wants but does not make.

When you know a little bit about what you want to build, and maybe even a bit about _how_ to build it - when you have some actual experience, skill, and will - then the right advice is typically to slow down and think it through.

<comment><USER7> I have a theory that the extent to which the "Balmer peak" actually exists is the extent to which it makes the "just do it" advice easier to follow.

</comment></comment><comment><USER8> What keeps me from coding is not necessarily optimization (well, at least its connotation connected to speed), but maintainability...By that I mean the constant battle between, "Do I write the boilerplate I need to set this up right?" and "Let me just copy/paste/mock all of that". To me, this is a more sapping concern than optimized code, because taking too many shortcuts makes the project harder to maintain in its midstages...even worse, the shortcuts can cause sloppiness to cascade into the design of all the other dependent objects and interfaces.

Doing some nominal TDD has helped quite a bit for me, because it does require writing code, but not code that I have to worry too much about (and if it happens to be a pretty shitty, shortsighted test, I can delete it without it, theoretically, hampering the app) screwing me over. Sometimes this physical act is enough to get me past the code-writing block.

Also, if I actually do the testing right, it prevents regression, improves code quality, etc. etc.

<comment><USER9> I think it ultimately comes down to "choose the right tool for the job". TDD is just one tool that you have in your toolbox to accomplish whatever project you are working on. That doesn't mean that TDD is appropriate for _every_ project.

</comment></comment><comment><USER10> It's an oldie but a goodie. Fred Brooks:

"Plan to throw one away. You will anyway."

The mistake most people make is that they mix learning and doing in a single round. It's much better to write a prototype with a specific goal of wringing as much knowledge from it as you can without being distracted by scalability or maintainability minutiae. Then, and only then, will you be ready to write The Real Thing with all of the bells and whistles. In the end you'll probably save more time than if you kept going back and forth waterfall-style between learning and doing on the same codebase. You'll certainly end up with a better result.

P.S. That quote is from 1975. To quote another great mind (Santayana): those who do not know...

</comment><comment><USER11> I remember when Facebook's front page code leaked. I am no PHP expert, but it was pretty ugly code. Probably today you couldn't get hired at Facebook if you wrote code like that.

[http://techcrunch.com/2007/08/11/facebook-source-code- leaked...](http://techcrunch.com/2007/08/11/facebook-source-code-leaked/)

I've heard many arguments where people will tell you, it won't scale. Or you're doing it all wrong by writing quick and dirty procedural code. Quite frankly scaling is about the nicest problem to have if you're a startup. Without traction your ugly code simply isn't going to matter. With traction you will gain funding and the ugly code problem quickly disappears like I assume it did at Facebook.

<comment><USER12> > Quite frankly scaling is about the nicest problem to have if you're a > startup.

I'm certain I stole it from someone here on HN years ago (whoever it was, I owe you a beer!), but I've always called this a "Maserati Problem". That is, it's something I can think about while I'm driving down the road in my Maserati that I've purchased with money my startup has made already.

Scaling, in most cases, is a problem very much like "where am I going to store all this money that's pouring in?!" If you have it, you've already won.

</comment></comment><comment><USER13> I'm by no means a pure functional programmer, but I've found some of the mantra from that paradigm helps when building the early blocks of a program as it allows you to break down your application into core problems which can be tackled individually. Plus it allows your application to scale easier and makes it easier to rip out and replace code as you start to add complexity.

But of course, before starting any major project, the first thing any developer should do is map out _at least_ a basic mental design of the program - even if that map isn't written in pseudo-code or in a form of a flow chart.

<comment><USER14> in other words, FP evolved to solve _hard_ problems. You don't need to understand monads to model a cash register. You probably do need monads if you want to write a bug free distributed asynchronous system.

<comment><USER15> I don't know that you need monads, but a lot of recent languages seem designed to guide programmers to certain types of good design. You don't _need_ the language to emulate the design ideas.

</comment></comment></comment><comment><USER16> I've missed coding with whimsy and curiosity. There was a time in my life when it wasn't all _engineering_. Characters from the Lord of the Rings trilogy made their way into tutorials and references to the Flying Circus were everywhere. Communities were a lot more accepting of newcomers and few people were so paranoid of _bad, unmaintainable, spaghetti code_. There was less of a focus on being a _10x developer_ and more on learning, having fun, and doing neat things.

I'm probably remembering things with rose-tinted glasses.

These days, even in open source -- the once proud land of eccentric hackers and the _can-do_ spirit, there is such a negative focus on _bad developers_. I can certainly see how the OP could feel paralyzed when just trying to write a line of code.

In reality we're all at different points in our journey and have had different experiences along the way. There's always room to improve ourselves and it's important to listen to criticism so that we know where to start. But sometimes you just need to cut loose and let it all hang out. I started writing a library I call "Horton," for this very purpose: _whimsy_ , _pleasure_ , and most of all to _avoid_ the engineer mindset!

In order gain insights and develop new ideas you have to find new hunches and investigate them. It's hard to develop hunches in a vacuum where your reality doesn't expand beyond your own self-made bubble. You've got to push once in a while... and people out there who complain so loudly about _shitty_ developers? Get a life and help someone out. We're just making programs.

 _update_ : <https://github.com/agentultra/Horton> forgot the link...

</comment><comment><USER17> I don't know--my impression is that most people go to far in the _other_ direction. They write code with no thought at all for the future, and then shortly have nightmarish debugging sessions in spaghetti code that's impossible to extend or reuse. All in the name of a rather extreme "worse is better" philosophy.

I've certainly experienced this with some of the people I worked with recently. Anything you win in the short term gets lost several weeks--if not _days_ \--later when everything is a horrible mess. Don't even think about coming back to that code months later!

I've found that putting in a little bit of care for the future pays off even in the short term. Perhaps not on the scale of hours or days, but definitely _weeks_. Which is still pretty immediate.

However, _how_ you do this is also very important. The handy rule I've been using is simple: simplicity. Improve your code by making it do _less_ not _more_. If you can make code more maitainable or general by simplifying, do it. If it would require adding new concepts or mental overhead, reconsider. Try to reuse existing abstractions as much as possible.

This usually--but not _always_ \--means making your code more functional. Do you really need to write this operation in place? Do you really need to tie everything together with a bunch of implicit state changes? Probably not! This is not to say that you should _never_ use state: just be sure to only use it when it fits well and makes sense. And be explicit about it.

The functional style (at least in languages like Haskell) also lends itself very well to reusing simple and general abstractions. The key idea here is that these abstractions are _not_ about doing more: they're about doing _less_. More general code simply leaves you less room to make mistakes. If you're working with lists of numbers, there are all sorts of arithmetic mistakes you can make; if you manage to write the same code against lists of _anything_ , the only mistakes possible will be in list handling.

Haskell just makes this more practical by providing abstractions with a great "power-to-weight ratio": ones that manage to be simple, general and yet still expressive. Code with functors or monoids or traversables is easier to write than more concrete code and yet still flexible enough for many useful tasks. As a bonus, it's also more reusable. For free.

So the key idea is reduction: all these abstractions work by _stripping_ concrete types of power. A functor can do much less than a list. A monoid can do much less than a number. This lets you write nicer code without becoming an "architecture astronaut" because instead of adding structure, you're really taking it away.

I've found that programming like this _really_ helps in maintaining and extending the code later on. But it doesn't slow me down when I'm writing either--I actually _save_ time because I spend less getting time getting the code correct in the first place.

These days, I've started being able to make large changes or add complicated features and have them work on the first try. Not every time, but surprisingly often. Certainly much more often than before! In large part, I think this is because of writing the code with an eye towards simplicity.

So the important insight: take the _simple_ route, not the _easy_ route.

<comment><USER18> If you write code too slowly, go faster. If you write code too quickly, go slower.

You can tell if you're too slow when you've spent two weeks thinking about the program and have neither working code nor a detailed design, or if you've created a detailed design only to realize upon implementation you'd gone about it entirely the wrong way.

You can tell if you're too fast if you find yourself spending more time cleaning up messes of poorly-thought-out spaghetti code.

<comment><USER6> This is like in go. If your walls are too brittle, play more conservatively. If your walls are too thick, loosen up. You can make generally better moves in go just by recognizing if you are too conservative or too aggressive. Same with poker.

<comment><USER19> Upvoted to make up for MBlume's mistake. :)

<comment><USER20> Upvoted again, because I felt like it. But it's still one upvote short, I guess.

<comment><USER21> Fixed. :)

</comment></comment></comment></comment></comment></comment><comment><USER22> This is good advice when you're new to a stack.

But, if you know better, do better please.

After writing tons of code, I've come to realize that 80% of the time, it takes about the same time to do it "right" (scalable/secure/modular) as it does to do it "OK".

Ex: Are plaintext passwords any faster to build/code than encrypted+salt passwords? Nope.

And, it's fine to intend to refactor later. But, too many organizations have no tolerance later to let engineers do things that don't have visible results. I've suffered through a stint of handling "legacy code" like that & it was painful & demoralizing.

</comment><comment><USER23> In general writing a trick to get around this is to do a 'vomit draft' -- intentionally write something bad.

In part, this is simply to get past the analysis paralysis or creative block and get going on something. But also because it can sometimes be easier to make something good when you have a clear bad example in front of you to contrast it with.

</comment><comment><USER24> (From a couple of years ago: <http://dvt.name/2010/ward-cunningham-on- simplicity/>)

Occasionally, I find myself "stuck" when writing code – the coder's "writer's block" I guess. This quote by Ward Cunningham is both inspiring and truthful:

\-- Once we had written it, we could look at it. And we'd say, "Oh yeah, now we know what's going on," because the mere act of writing it organized our thoughts. Maybe it worked. Maybe it didn't. Maybe we had to code some more. But we had been blocked from making progress, and now we weren't. We had been thinking about too much at once, trying to achieve too complicated a goal, trying to code it too well. Maybe we had been trying to impress our friends with our knowledge of computer science, whatever. But we decided to try whatever is most simple: to write an if statement, return a constant, use a linear search. We would just write it and see it work. We knew that once it worked, we'd be in a better position to think of what we really wanted. --

Next time you're stuck, just write the simplest thing that could possibly work!

\-- So when I asked, "What's the simplest thing that could possibly work," I wasn't even sure. I wasn't asking, "What do you know would work?" I was asking, "What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen, instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it. If it needs to be more we can make it more. Our problem is we've got nothing." --

Source: <http://www.artima.com/intv/simplest.html>

</comment><comment><USER25> I write news articles in addition to code, and a fellow writer gave me a simple piece of advice that I think applies to both disciplines. It has to do with planning -- but not over-thinking -- your work.

Before you start writing, sit down with a friend in a bar and explain to him exactly what you're trying to say and do. If you can't communicate your idea in a concise, conversational way, then you're not ready to start writing.

Applied to code, I suppose this is similar to the concept of Rubber Ducky Debugging: <http://en.wikipedia.org/wiki/Rubber_duck_debugging>

</comment><comment><USER14> you need to learn calculus if you want to model relativity. you only need fifth grade math to model a cash register.

if your team builds apps with 500k LOC, you need to be constantly focused on abstracting and factoring out patterns or you will drown in your defect rate before the project even ships. If your team builds medical device software, if you aren't doing this, you'll get someone killed.

If you're building a personal blog, your time is better spent by pasting jquery snippets.

There is a spectrum here and most projects fall somewhere in between.

<comment><USER26> Of course. And to add an example of the other part of spectrum (opposed to medical device software) - bunch of simple 2d game prototypes. There's people who do such jobs, and many similar, who'd be a fool not just "push the buttons" _all the time_ , with basically just a quick forethought related to structurization and code quality.

</comment></comment><comment><USER27> I can identify with this. Some of the best work I've ever done has been some of the worst code, just because of the paradigm shift involved: "get shit done" instead of "write nice code".

</comment><comment><USER28> I understand completely.

"And all that is fantastically interesting, but completely beside the point. I just fell into the classic programmer trap of exploring and learning about (what I find) fantastically interesting things that will address all sorts of amazingly complex situations, _but which the learning of said things resulted in absolutely nothing of tangible value being created_."

<http://www.jamiebriant.com/blog/2013/1/fireworks.html>

</comment><comment><USER29> I disagree. Too simplistic. It's my job as a developer to try and think of all the ways my project can fail and bog down before hand (within reason on the performance). I've got a list of items I am actually working on and will post it above my desk when done:

1\. Let me think about this some more before giving you an answer.

2\. I will use my debugger.

3\. I will create a new branch for this task.

4\. I have commented my code and commented it well.

5\. I have accounted for fail scenarios.

6\. I have considered multiple solutions to this task.

7\. I have not begun hacking away immediately at a task.

8\. I have attempted exploiting my code.

</comment><comment><USER30> Here's what I came to after 10 years.

1\. Write code fast.

2\. Refactor when necessary (either because you got to a dead end and can't keep writing code fast anymore, or because you're done and want to move on to another task).

3\. Goto 1.

</comment><comment><USER31> The problem with this approach, while great for you, the developer it is a nightmare for the future team.

I am now working at a startup where the early devs have left. They did precisely what was needed at that point - build quickly, ensure it works for the 3/4 customers we had back then and document it as well. Fast forward a year later, that same code is no longer extensible for many clients. Its rigid and tightly coupled and rewriting some parts means, we have to pretty much rewrite a whole lot more than we bargained for. We will have to burn through a lot of cash to just build a whole new product based on some of the scalability and maintenance learning we now have from a year of learning and growing to client# 100.

The point is, there is always going to be "this is the right thing right now, its what our customers want" and then something else for the future.

I have seen that people who have worked for a while and in many startups do the smart thing (as expected) and while follow "build for now" they also do the sensible thing of investing for the future (from experience).

</comment><comment><USER32> I can relate to this. There is a real risk in freezing up when you attempt for your first writing of code to be the fully architected solution.

I would still go one step further and at least apply the strategy pattern/polymorphism when you have a large if/else/case block going beyond 2 or 3 conditions in a controller or model or something. (assuming MVC web apps)

The fact is you can write out some ugly code directly in a controller where it might get some code working fast and prevent the freeze up of your output, but once working you should immediately move it to the appropriate place like a model or library, and apply a basic OO strategy pattern (perhaps not with factory/interfaces etc until needed later) where appropriate to cut down on spaghetti/nested conditionals.

This really does not take much more time than stopping at working code that is ugly, and is a good middle ground where it is not painful to return to later.

There is still no good excuse for "taking a dump in the corner" of your code base just to get a marginal gain in output.

</comment><comment><USER33> I can relate to this, somewhat. I've spent quite a bit of the last few years writing code either under deadline, or for work that's ultimately charged hourly. That doesn't lend itself to thoughtful refactoring.

As such, when I'm not under those constraints, I sometimes go a little overboard factoring out duplicated code and looking for the beautiful solution. To me, beauty is the maximization of clarity _and conciseness_. Since I'm usually writing Perl, there's quite a lot to work with in that regard.

For example, yesterday I spent 4-6 hours writing approximately 40 lines of Perl (along with another 40 lines of tests).

On the plus side, what I generate during these binges is generally an efficiency multiplier for the other code I write, as well as a god way to really examine some of the more esoteric, but useful, ways to use your chosen language.

</comment><comment><USER34> This is a great post. I just wrote about a project I worked on in February[1]. When I first built the website, it wasn't optimized and now I realize that I greatly over estimated how many resources I thought the site would need.

Last week, after getting to the first page on Google's search results, I'm getting about 12,000 hits a week. Monitoring shows my daily CPU usage is nearly 0%, and memory usage around 32MB. Today(3 months later) I finally did some SEO, added compression, caching, and a CDN to get drop page load time from ~2 seconds to under 500ms.

[1] <https://medium.com/look-what-i-made/5d808ce36277>

</comment><comment><USER35> "Build it, release it, analyse it and only then decide if it needs optimising." I think it depends from company culture.

The thing is if you don't do it right with first go you will have hard time to get it done later. What management cares if it works, it's your responsibility to make it right from the start and they probably won't give you time to make some refactoring/optimizations later, because time is money :(. Sometimes it's hard to explain consequences. I have seen this too many times.

I believe you need to find golden middle, by not trying to hack things to much or overengineering problem, though sometimes is hard to define where is this middle.

</comment><comment><USER36>
      A complex system that works is invariably found to have evolved
      from a simple system that worked.

<http://en.wikipedia.org/wiki/Gall%27s_law>

</comment><comment><USER37> "We are what we do repeatedly." If you spend time thinking about best practices, it becomes easier and less time consuming. You need a balance of it early in your career but if you're constantly working at it, it'll become second nature. In my opinion, the best programmers are the ones who have exceptional practical wisdom, who know when to utilize a rule and when to yield to exceptions (no one likes a ferengi programmer -- [http://www.codinghorror.com/blog/2009/02/the-ferengi- program...](http://www.codinghorror.com/blog/2009/02/the-ferengi- programmer.html)).

</comment><comment><USER38> _Build it, release it, analyse it and only then decide if it needs optimising._

I often share a similar sentiment with teams I work with: _Don't throw solutions at undefined problems._

That commonly applies to performance and premature optimization.

I'll agree that there needs to be some thought as to what's being built before, and while, doing so, but spending time resolving as-of-yet-undefined problems means decision making based on high levels of uncertainty.

Get something working and let problems define themselves. Often times, they do so in a way that makes them easier to fix vs. relying on the speculative solution making I mentioned above.

</comment><comment><USER39> This calls to mind what Zed Shaw wrote about creative and defensive programmer mindsets. <http://c.learncodethehardway.org/book/ex27.html>

</comment><comment><USER40> So what's this "velocity newsletters" campaign Medium is running in their URLs?

</comment><comment><USER41> There are thousands of guidelines and many of the contradict each other .. there are many advisors creating posts, tutorials, patterns but I think you should work the way your ecosystems require it , don't try to be perfect just get things done and ensure your code will work in critical cases. Sometimes I wish I could be up to date in all the best practices but is just impossible some developers like me we work with deadlines and there's not much chance to try new things.

</comment><comment><USER42> A few more comments on this from earlier this week here: <https://news.ycombinator.com/item?id=5736911>

</comment><comment><USER43> One thing I've learned from having to do rapid prototype development is to just put fingers to keyboard and go.

If I find myself getting stuck in the cycle of "this can be written better, I'll just spend 2 hours improving it rather than finishing the framework" I stop, I think about it, then I leave the working-but-probably-crap code in place and move on.

Once the framework is in place, then I start making things better, one area at a time.

</comment><comment><USER44> Thinking about scalability or portability of the code from day 1 is useful because it may be difficult to crowbar those things in on day 200.

That said, don't dither too much over writing code. History favours the doers rather than the vacillators. Most software except for utilities has a quite short working life anyway. There is also the standard advice of "expect to throw one away".

</comment><comment><USER45> Actually you need to stop earlier, I've found that quite a bit of the stuff that people think they need to have built isn't even close to needed in reality. In fact, building it and shipping it can be a major mistake itself.

So I completely agree on the underlying principle: Dont to _anything_ prematurely, and that first and foremost includes actually writing any code at all.

</comment><comment><USER46> This point is very like an engineer's point, which have many years of development experience. He tell me when I'm a intern in the company. I always like to write perfect and complete code that time. But you must _write_ code first, so that other people could cooperation with you. Just write and see and test, then you can find the problem.

</comment><comment><USER47> This is the god-knows-which time this link surfaces on HN and I keep saying the same thing - once all this stuff is ingrained you don't think about design patterns, you just do them. Either that or you decide what to do in a design session or on the whiteboard.

Thinking about this stuff is the sign of either a newbie or lacking up-front design.

</comment><comment><USER48> There's a freaking huge difference between double checking every single line of code, and coding a new features (hundred, thousand of lines of code) with a scalable design.

Does that resonate enough for you?

Seriously, seeing stuff black&white is how bad code happens. (And so many other things in life.)

</comment><comment><USER49> With experience, you will know where you need to put a little extra effort in to avoid having to rewrite it later because it's too slow.

Also, test your app with LOTS of data. Even during early development. A slow algorithm/query will become very obvious under a high load.

</comment><comment><USER15> There's another approach from polya's _how to solve it._ If your problem is too hard to solve, find an easier related problem and solve it first. Which I guess is sort of like applying an MVP to parts of the project as well as the whole thing.

</comment><comment><USER50> Sure, go hog wild on anything and everything... except protecting my privacy and security.

</comment><comment><USER51> Just be prepared that if you write a service that does not scale, that will eventually bite you painfully bad with massive amount of data going nowhere but stuck in the stupid relational database with terabytes of data.

</comment><comment><USER52> Like most things in life, I feel like a sense of balance is the most important thing to be aware of. Jumping into code too quickly is just as bad as trying to design the perfect system from your head.

</comment><comment><USER53> Good design isn't optimization. The trick is to do it so often as katas that you internalize it. Then you see the better way to do things and just do it. No stage fright, just action.

</comment><comment><USER54> See <http://www.canonical.org/~kragen/tao-of-programming.html> pay close attention to section 4.4

<comment><USER54> oh, and to piss off many, see section 2.4.

</comment></comment><comment><USER55> word! If I think of all the projects I started and didnt finish becuase I overhtought and overengineered and often just froze.

</comment><comment><USER56> I'm not sure I agree about this with respect to security, even though security can be a huge time investment to account for.

<comment><USER12> As a security professional as well as developer, I agree with the OP. Simply put, you're going to screw things up no matter what you do. Be smart about it, plan for the worst, and seek outside feedback into your security processes; you're never going to find all the edge cases, even if that's your day job.

</comment></comment><comment><USER57> Ah, it's important to write the code for easy replacement, at least. Make it easy to kill only chunks.

</comment><comment><USER58> This is a good idea if your time in the future is worth less than your time today.

</comment><comment><USER59> Don't be scared... Just hack something together and have fun!

</comment><comment><USER60> Same school of thought: 'Write Code Like You Just Learned How to Program' - <http://prog21.dadgum.com/87.html>

<comment><USER61> That article is simplistic. Sure, write code that you won't care about in the future like you don't care about it, but if you take that approach with anything requiring longterm reliability or maintenance then you're setting yourself up for failure. Essentially: Think about it. Use techniques and tricks where appropriate, but at least consciously make the decision to do a less than stellar job and document your reasoning. A couple of lines of comments justifying some weird and verbose approach might show to others that it wasn't the lack of mental capacity to come up with another implementation.

<comment><USER60> I believe the spirit the article was written in has value. Obviously one should use common sense and still apply the best practices that they know of at the time.

</comment></comment></comment><comment><USER62> The Bad Guys want you to feel insecure about your work, your position, your relative standing, and everything else because their worst nightmare is that software engineers and scientists and thinkers wake up and realize how much leverage they would actually have if they were organized and capable of looking out for their own interests. We'd reshape the entire business landscape, and the power relationships between us and them would be inverted.

They prey on the insecurity of the smartest people. It makes us easy to take advantage of, and compromises almost all of our leverage.

Every time you let them sit in your head and natter about how your work isn't good enough because it doesn't isn't in accord with what they see as "professional", you're letting them win. The problem with assholes is that their imprints live on even years after you get away from them. It takes conscious effort to get that lingering cognitive load out of your mind.

We need to step back and simplify: solve problems, and do it well. (This includes documentation and testing, when appropriate.) Make stuff, make it good, make what's good better. We need to get back to that, rather than slugging it out over "agile" and TDD and nonsense. Zed Shaw got it right: <http://programming-motherfucker.com/>

<comment><USER63> Really? From my experience the "Bad Guys" don't give a shit about code quality and will shower you with praise if you give them the crappiest code possible, as long as you make the changes they want 5 minutes ago. This article is really talking about the insecurity that other programmers inculcate, because we're all very smart and all very competitive.

<comment><USER62> The Bad Guys don't care about code quality, but they want programmers to be insecure. They do, however, play divide-and-conquer games against programmers and encourage our own cannibalism (e.g. long email flamewars about tabs vs. spaces) as well as that rockstar/ninja bullshit.

<comment><USER64> Wait, flamewars about spaces vs tabs are part of a conspiracy to keep programmers insecure and frightened? You'd better explain that remark.

<comment><USER62> Executives don't care about that specific flamewar (or even know that it exists) but they _like_ creating environments where we slug each other over minor, superficial differences in coding style because (a) it makes us look stupid and petty, and (b) it tires us out and makes us even easier to steal from.

Programmers are often oblivious, when they find themselves in work environments that are designed to play divide-and-conquer games against them, to what is going on. Executives often enable/encourage the worst traits of programmers in order to weaken the group.

<comment><USER65> Please seek out a therapist to talk to. You can't be happy with the level of anger and resentment that you seem to have right now. At first I thought you were an attention seeking jerk, but after reading your comment history, I think you have gotten yourself into a bad place in life. Please consider it.

<comment><USER66> Shut up, jerk.

</comment></comment></comment></comment></comment></comment></comment><comment><USER67> I can't scroll that website by pressing the space key. The article is not worth reaching for pgdn.</comment>


Atom 1.20 - <AUTHOR> http://blog.atom.io/2017/09/12/atom-1-20.html <comment><USER2> I was a fan of Atom until I tried VSCode. Call me a shill, if you will, but it is an all around better experience and I haven't looked back.

<comment><USER3> Why shill. It's just great tool. I love lots of what MS does. I still consider C# best language I ever learned.

<comment><USER4> I loved c# 10 years ago but have a few issues with it these days:

* functions not really being first-class citizens * great collection methods with LINQ, but why did they give them such weird names? (map = select, filter = where, reduce = aggregate?) * took them a while to come up with a great async model (async/await), so legacy c# asynchronous code can be hard to figure out at first

Just my opinion but it seems like more recent languages like Swift have done a better job implementing ideas from functional programming. It's still light years ahead of Java to me though.

<comment><USER5> >but why did they give them such weird names? (map = select, filter = where, reduce = aggregate?)

SQL.

</comment></comment></comment></comment><comment><USER6> How about reducing the memory footprint?

<comment><USER2> You were downvoted to oblivion, but honestly this is a huge issue that somehow feels like people are just OK with.

Honestly, work with Atom open for a day or two on the same project, that's not uncommon right? Prepare yourself for some serious type lag.

Full disclosure, I run a Linux desktop with 32GB of RAM. I'm not accustomed to type lag. Judging by your downvotes it's an acquired taste.

<comment><USER7> I downvoted paule89's comment because it felt like a cheap shot at an established product with well-known pros and cons.

Yes, Electron apps consume a bunch of RAM. Yes, Rust needs you to deal with data lifetimes. Yes, Go still doesn't have generics. Yes, Haskell has a steep learning curve if you learned imperative languages first.

No, restating those facts on HN at every opportunity is not constructive.

<comment> yjftsjthsd-h Rust is built on lifetimes, Go is designed to not have Generics, Haskell will always be weird. A UI toolkit has no inherent reason to use a large amount of resources, so there is some value in noting that they either don't care or haven't managed to fix it yet.

<comment><USER8> Rust is built on lifetimes but the compiler could definitely infer them better. Not only from my experience, but all attempts to introduce coworkers / anyone else to Rust usually meets a "this 'a thing is ugly and awful and I hate it".

Really it was more a design decision on the language part than something it was "built" on. In 99% of cases the compiler can identify where _exactly_ you need to annotate lifetimes to sate itself. They are only there for explicitness. Tagged lifetimes will help a lot with this, because it is much more intuitive for anyone using any other language to say "ok I need to say result R lives as long as argument A that makes sense" vs "stick an 'a on everything" and have functions that have nothing to do with generics _looking_ like generics to the average joe.

I know I personally have written function signatures to take (or return) owned data in Rust _just_ to avoid having to lifetime annotate the whole thing. It is just a chore that most of the time is just boilerplate to "make it obvious" to readers of code, despite almost every situation I see lifetime annotations I can straightforwardly understand that the & in the return is lifetime bound to the & in the arguments or the struct field it comes from.

</comment></comment></comment></comment></comment><comment><USER9> I'm really impressed with the tick-tock of Atom development. Their turnaround time on releases with major new features in each release is really something to see.

And, it's a pretty decent rebuttal to the questions folks raise about the decision to build on Electron in Javascript. The tradeoffs are big (memory, startup time, performance), but the benefits are maybe bigger (huge dev community, tremendous resources being thrown at the biggest problems in the form of work on the JavaScript engine and language, easy-ish entry for new developers, etc.). Even with all of its flaws, it's still a better experience enough of the time for enough of the people that it's become one of the most popular editors almost overnight.

</comment><comment><USER10> Still prefer Sublime over Atom. I can't stand software that wastes Memory like Atom does.

Then again Atom has a nice UI. Maybe in the future...

</comment><comment><USER11> Atom 1.21 features support for the language server protocol

<comment><USER12> Wow, that's a big one! I'm eager to try Atom out again after being burned by speed issues years ago.

<comment><USER13> Those aren't gone.

</comment></comment></comment><comment><USER14> Every update I hope there won't be lag, but sure enough there always is. Leave it open for a whole day and text input + browsing a project tree will freeze periodically. I'm on a maxed out Mac too...

<comment><USER15> You could try running it with no custom plugins. If it still happens I would report the issue at their GH repository.

As others above have said, me included, never experienced what you describe.

</comment></comment><comment><USER16> I've tried all the editors, when it comes down to it I always end up going back to some combination of Sublime + Vim. I prefer to do most things on the command line rather than set up IDE configurations, so a plain text editor suits me just right.

I like the customization of Sublime, and I've got it setup just how I like. In a way, Vim is similar... once you get it customized perfectly, there isn't going to be another text editor that beats it.

VScode is nice, but I don't really see any pros to it that would make me switch from Sublime, other than the Debugger maybe (which I never use).

<comment><USER17> What's your combination of Sublime and Vim?

I've recently switched from VSCode to Vim and have really started to like it. I try to use Vim keybindings in everything I do, including browsing on Chrome with the plethora of Vim-like extensions.

I still use Sublime, mainly for its multi-cursor editing power. I don't there's an editor that can really match Sublime's multi-cursor feature. I know there's a way of doing in in Vim, but I'm still learning this language, and it seems like a difficult concept for me to grasp right now

<comment><USER16> I just meant that I use Sublime and Vim as my primary text editors. I do use the "vintage" mode in Sublime also, which mimics some of Vim's functionality.

</comment></comment></comment><comment><USER18> By how has the performance improved? The last I checked Atom was way too slow as compared to other editors even VSCode.</comment>


(WSJ Paywall): How 'Hoverboards' Epitomize Our Broken Patent System - <AUTHOR> http://www.wsj.com/articles/how-hoverboards-epitomize-our-broken-patent-system-1450674060 <comment><USER2> Non-paywalled link : [http://www.wsj.com/articles/how-hoverboards-epitomize- our-br...](http://www.wsj.com/articles/how-hoverboards-epitomize-our-broken- patent-system-1450674060)

<comment><USER3> In what way is it non-paywalled?</comment></comment>


How Millennials Killed J Crew - <AUTHOR> https://www.nylon.com/articles/why-did-j-crew-die-millennials <comment><USER2> Don't these types of articles just have clickbait titles to get Millennials to comment in outrage at being called millennials?

J Crew "killed" J Crew by not adapting to the consumer right?</comment>


WSJ: Half of Jobs at Amazon's Two New Headquarters Won't Be Tech Positions - <AUTHOR> https://www.wsj.com/articles/half-of-queens-amazon-jobs-wont-be-tech-positions-1542829226 <comment><USER2> Not really surprising that an "HQ" (even if it's one of three) has a large percentage of centralized, administrative roles of various kinds?</comment>


Here's how you can set YouTube video playback rate to any speed you like - <AUTHOR> 1. Open browser console
2. Type in: $('video').playbackRate = 2.5
3. Enjoy <comment><USER2> If you use Chrome, a better option is to use Video Controller extension[1]. Works with any html5 video, and gives you a lot more granular control.

[1] [https://chrome.google.com/webstore/detail/video-speed- contro...](https://chrome.google.com/webstore/detail/video-speed- controller/nffaoalbilbmmfgbnbgppjihopabppdk)

<comment><USER3> I use this every day. Being able to quickly jump forward/backward 10 seconds is also very useful. I recommend setting keyboard shortcuts that agree with equivalent functionality on your desktop player like VLC.

</comment></comment><comment><USER4> There are also some chrome extensions that allow you to speed up any html5 video (so it works on youtube, Vimeo, and even Netflix!) highly recommended.

</comment><comment><USER5> I used to do this manually, but after a while I decided to create a simple website [1] containing bookmarklets that provide the same functionality.

[1] [https://www.videospeedup.com/](https://www.videospeedup.com/)

</comment><comment><USER6> Is there a way to do this on android too, maybe rooted phones?

</comment><comment><USER7> You would not find news like this in the new York times :)

</comment><comment><USER8> omg!</comment>


The 12 most dangerous superbugs, ranked by the WHO - <AUTHOR> http://www.vox.com/2017/2/27/14750882/deadliest-superbugs-world-health-organization <comment><USER2> (Ranked by the _World Health Organization_... not the rock band.)</comment>


The Revival of Semiconductor Funding - <AUTHOR> http://techcrunch.com/2014/08/29/the-revival-of-semiconductor-funding/ <comment><USER2> As someone trying to raise funding for a semiconductor startup in "silicon" valley, the biggest problem I see is lack of information. Most investors think that the minimum amount needed for a potentially (still very low chance) successful Semi startup is $100 million, which is nonsense carried over from the last century. I recently talked with a name partner at a very large (universally known) VC in the valley, and they thought that for a 5-10% chance at success, a fabless semi startup needed $100 million minimum, and to increase that to 30% you needed $250 million and hundreds of engineers. The only reason these ideas are prevalent throughout the venture world is because the market incumbents (Intel, AMD, NVIDIA, etc) want the rest of the world to think that they are the only viable companies so that new competitors do not form. Over the past 10 years the semiconductor IP (and standard cell) ecosystem has made huge progress, saving significant time and money on the design and implementation of parts of a chip that are not the startup's "secret sauce"... FPGAs and their tools have only gotten better, allowing anyone to test a new chip/component design with little more than a laptop and a relatively inexpensive FPGA. The fact that the foundries of the world have been able to lower the cost of multiproject wafer fabrication runs, making test of 50-100 chips of real silicon cost as little as $500,000 using a ~4 year old process to $2,500,000 for the latest (20nm) process. The fact that these fabs want to be producing at capacity means that the cost for getting to a full fabrication run (tens to hundreds of thousands of chips) can cost as little as $5,000,000 and goes up to about $15,000,000 depending on the fab and the process.

Realistically, a small startup of ~3 people should be able to prove something on an FPGA (and show good simulations for a produced chip) for ~$100,000-$250,000. ~5-10 people and $2 to $5 million should be able to produce actual chips, and depending on the process node, be able to produce a couple thousand chips and have revenue. No modern fabless semi startup that should exist that has the right team should need more than $15 million to be able to get to revenue and hopefully profitability. I've always believed and thought that it was a silicon valley idea that innovation happens with small teams with what are thought of as crazy ideas... and if they aren't able to do it with 1/10th of the capital and 1/10th of the number of people, and the potential to make something 10x better, then it is not a worthy startup.</comment>


Ask HN: I tired of web development. Should I move back to SDET? - <AUTHOR> I started my career as a Performance QA Engineer in a game development company. In Performance QA Team we were developing all kind of useful internal tools: log collectors and analyzers, reporting system, test management system, but I left the company because I wanted to be a "real" developer who's shipping a "real" product for end users. So I moved to web-development.
I've read "Code Complete", "Clean Code", "Extreme Programming Explained" and thought that "real" developers solve interesting problems and write maintainable and high-quality code covered by unit tests. I was wrong.
"Real" development and "real" products are crap. When you develop an internal tool you do it because of necessity. In contrast, when you develop a new feature for a "real" product you do it because of a manager's whim. After two years in web development and after reading HN I conclude that "real" development almost always goes together with inadequate deadlines, shitty requirements, and high level of stress. I'm one step away from burning out.
I want to change something in my career. Should I move back to Automation QA/Programming of Internal Tools? Have you had the same problem in your career and what decisions have you made? <comment><USER2> > _I 've read "Code Complete", "Clean Code", "Extreme Programming Explained" > and thought that "real" developers solve interesting problems and write > maintainable and high-quality code covered by unit tests. _

Remember that the people who wrote those books cut their teeth in the pre-web days. It was a much different world back then; there was a huge incentive to get things right the first time because patches were difficult to get to users.

Jobs like the kind you describe exist but are uncommon; usually they can be found in businesses that build tech products and platforms (software or hardware) or in the FAANG companies. Given your background, I'd suggest looking for a job at one of the games middleware companies if you haven't soured on the idea of being a developer entirely.

</comment><comment><USER3> I think if you are in the critical path of any company or project, you have to learn how to manage expectations and manage stress. It is a skill in itself.</comment>


Ask HN: What are lesser known / taught subfields of Computer Science? - <AUTHOR> <comment><USER2> Stenography comes to mind. It seems it just gets mentioned in cryptography classes. Not sure that's very useful though.

I think machine learning is not taught enough relative to it's growing demand.

COBOL is a language that is still used in many places and will need people to replace those who are retiring, so I feel that is lesser known and not taught in many places.

</comment><comment><USER3> Some I can think of:

\- Automata theory

\- Complexity theory (P vs NP stuff, not the one from leetcode problems)

\- Verification

\- Optimization using stuff like genetic algorithms, ant-colony algorithms, particle swarm, simulated annealing, etc. Not sure how to call that area. In my case it was an AI course.

\- Fuzzy logic

\- Scientific computing and Numerical analysis (CFD, finite elements, etc)

\- Information theory

<comment><USER4> > \- Scientific computing and Numerical analysis (CFD, finite elements, etc)

Yes please, if we could have more software engineers working on mechanical/aeronautical/civil/<physical> engineering tools that would be great.

Currently the state of the art takes a long time to get out of PHDs and into industry, and when it does it is in the hands of a few companies that sell expensive software licenses.

The likes of at Ansys, Siemens (NX), CD-adapco,

You can access FOSS tools like open-foam but the average engineer doesn't have the skillset to also wrangle the tool as well as their domain problem.

An area I was always fascinated with but never had chance to dig into it was topology optimization to generate structures (or flow paths) to accomodate some given boundaries and physics.

[https://en.wikipedia.org/wiki/Topology_optimization](https://en.wikipedia.org/wiki/Topology_optimization)

<comment><USER3> > Yes please, if we could have more software engineers working on > mechanical/aeronautical/civil/<physical> engineering tools that would be > great.

That was my favorite subject in college and I wanted to pursue that area but sadly we didn't have any experts in the CS department. All of them were from the Mechanical Engineering department and they were extremely disconnected.

</comment></comment></comment><comment><USER5> Program verification. How to design and implement correct programs.</comment>


Openmesh - <AUTHOR> https://openmesh.wordpress.com/ <comment><USER2> I can imagine seeing an increase of interest/participation of talent around the world for these kind of projects due to the recent events in Tunisia/Egypt.

it will be very interesting to see where these projects are heading to in the (near) future. this might be also quite interesting for those in stable democracies, where the fear of shutdowns is not that prominent.

</comment><comment><USER3> This won't fix the issue of networking with BGP and isp's</comment>


Ask HN: anyone ever drop everything and leave software dev behind? - <AUTHOR> I know most everyone that hangs out here sees themselves as hackers/coders/etc, but anyone ever leave the software world to do something unrelated? I've been programming professionally for 5 years now, and am at a point where I can't really take it anymore.
The problem?
* Golden handcuffs - I'm leaving a lot of unvested money on the table if I leave, and realistically speaking if I leave this job I won't get anything that pays nearly as well for years
* Lack of "support group" - sure I could up and move to <random country>, but I don't really have much of a social circle so I'm a bit daunted by the prospect of being even more alone
* Still want to code - I don't hate software, but my job has made me realize that I'm really just a mediocre programmer with really good domain knowledge
* Aspirations - if I leave the corporate coding world, all of the other things I really want to do aren't exactly less stressful - move to LA and become a filmmaker, move to SF and join a startup, etc.
On the plus side, I can afford to be unemployed for at least a year, so I'm seriously considering just quitting outright to figure things out (with the caveat mentioned above that once I leave, coming back to this job/pay level is not going to happen). Anyone have similar thoughts/experiences/stories? <comment><USER2> _I'm really just a mediocre programmer with really good domain knowledge_

Your problem is that you have no problem. Let me explain...

I believe that the "quality" of a programmer is not how much you know, but what you can do with it. So it you have "really good domain knowledge", then you probably aren't a mediocre programmer at all, you're probably a good programmer or even better.

Like many other hn'ers, I love to come here are check out the latest cool stuff people are doing. Then I hear the 2 voices in my head. One says, "That is so cool - I have to learn that!" The other says, "Big deal, I could do that in BASIC. I may need a few more lines of codes and a couple of hacks, but it will still do the exact same thing."

It's tricky to balance all the cool stuff going on with your ability to _just get stuff done_. You will never learn everything. You will never become the expert at more than one or two things. It's great to _learn_ , but not at the expense of _doing_. You need both. There were many times I had to build something with my limited knowledge and wished I knew more. But then I built it anyway. Something built with limited resources today is better than something built perfectly tomorrow.

If you're unhappy with your job but like coding, then either find another job or start something on the side. But please don't fall into the trap that you aren't good enough because _someone else_ knows _something more_. That will always be the case. You can't win that battle.

Just do the best with what you have and make a practice of adding to it a little at a time. Get satisfaction from the benefits you provide others with what you know now.

<comment><USER3> great advice (as usual), edw519 ... have you thought about starting a blog with an FAQ mined from your responses from "Ask HN" questions? an easy hack that someone else could even do would be to troll through "Ask HN" threads, extract the ones where your answer was highest-ranked, and slap them together on a webpage somewhere. then that could be manually filtered and curated. i think that this would be a helpful page for young programmers just getting started with their careers

<comment><USER2> Thanks for the kind words, pgbovine.

Yes I have thought about starting a blog for some time, but I was always afraid it would take time away from my programming.

Oh, what the heck...

<http://edw519.posterous.com/>

I have updated my hn profile.

Now I have a weekend project.

</comment></comment></comment><comment><USER4> First of all you mentioned two "unrelated" examples - one of which sounds like exactly the same thing in a different environment. Being a film maker is not a job either - I assume its like most creative industries and that 90% of the people who do it don't actually make a living wage. That's not to say don't do it but do think about what you are up to.

All of this suggests that its the moving on and not where you are moving too you are focused on.

Secondly - you don't sound like you have any dependants or responsibilities. So - best time in your life ever to make a move. (plus you can live for a year without income! Luxury!)

Thirdly there is _never_ a best time to do _anything_. If you wait for all the conditions to be right you will still be working at the same job when you are 60 still hating every minute.

and lastly in general you get to pick one of a) safe or b) interesting in a job - it is very rare to get both immediately.

You are young and free - and if you can't pick (b) now you never will be able to. If you pick (b) now you can always go for (a) later or you will find a niche where your type (b) job acquires some safety

and ps. Corporate programming _is_ totally rubbish for the most part in my experience and your feelings about the job are not the same as your feelings about software development.

</comment><comment><USER5> My story is quite similar to yours. I was a software developer for several years. It was intensely disillusioning and after thinking the same thoughts as you, I quit. I've been unemployed for the last year and a half, trying to "figure things out."

It doesn't feel like my sabbatical has been a huge success. But in the future, I might look back and realize it was essential. It's been relaxing, and I've done a lot of reading I wanted to do, but my reading list is still infinitely long (one book references another, ad infinitum). I haven't figured out what my life's work will be, and I feel a bit foolish for ever thinking I would.

You can take this as a kind of warning: a sabbatical may be the best option available to you now, and it may be exactly what you need, but don't expect it to be magical.

</comment><comment><USER6> I have a friend who dropped his career to go be an emergency medical tech / wilderness firefighter for about six years. He was/is a top operations guy, network guru, Plan 9 contributor, etc. etc.

Recently he got a bit tired of the firefighting life. Workplace politics mostly, believe it or not. Also, an interesting contrast: in the tech world, you can advance as fast as you can learn things. Not so in the firefighting world, where it takes years to convince others of your skills and to lobby for a good position on an elite team.

So he jumped back into the startup world and he's doing great. What he doesn't have in recent social contacts he more than makes up for in fundamental skills.

So, just a data point - it is possible to leave technology behind for a little while without ill effects, especially if you have deeper skills. If you're only good at the latest web framework du jour it's probably more of a gamble.

</comment><comment><USER7> I remember after the first tech bubble burst back around 2001 a lot of (young / male) disillusioned devs abondended the internets to become bike messengers (although they returned to blog about it naturally). It was an awesome read - if anyone remembers that and has some links please share. Some points I still remember:

\- A lot less money (as mentioned here by a few).

\- A lot less coffee. Being really tired at the end of the day (but the good tired after having felt as though they really worked). No more trouble sleeping. Keeping normal hours.

\- Harder. Faster. Stronger. It is hard work, but it makes you hard.

\- Few regrets (that I recall).

It was a little Fight Club-y. And I don't think anyone looks to retire as a bike messenger (probably get taken out by a taxi before then). But I'd be curious to know how long the experiment lasted.

<comment><USER8> A Coder in Courierland: <http://www.kuro5hin.org/story/2005/3/19/133129/548>

</comment></comment><comment><USER9> I went in the opposite direction. I was an engineer, with a promising career path, but became very disillusioned in the corporate [automotive] atmosphere, and quit to work on my own projects as a developer. It was very daunting to up and walk out on my experience and 2 degrees, but I think it was one of the coolest things I've ever done with my life.

Now I have my own office with a huge window, my guitar and skateboard hanging on the wall (they both get a lot of use throughout the day), and I make more money on average (to my own surprise) than I did as a full-time engineer.

I wouldn't trade it for the world, and if I hadn't tried, I'd probably still be sitting at my same miserable little desk in that same miserable little cubicle, with the same slightly wacky boss.

DISCLAIMER: I had started down the entrepreneurial path a few years before I quit and had spent every waking moment on my own companies on the side. I wasn't making enough to quit when I did quit, but I had lined up a few months' worth of contracting work, and figured that would be long enough for me to get on my feet.

</comment><comment><USER10> I left programming in 2004-2005 to work at a skateboard company. I filmed and edited videos and went skateboarding for a year. It was great. I also only made $8000 the entire year, most of it from fixing the company's web site, so I returned to programming.

<comment><USER11> Did you have trouble returning? Was it hard finding jobs, getting interviews? Did you have to take a pay cut when you returned?

<comment><USER10> _Did you have trouble returning?_

No.

 _Was it hard finding jobs, getting interviews?_

No.

 _Did you have to take a pay cut when you returned?_

No.

<comment><USER12> what kind of programming did you do?

<comment><USER10> a bit of everything

<comment><USER12> :\ really no focus? even something general like, "web development" (as opposed to "game development", "financial software").

i'm curious because i wonder what fields it's easy to find work in again after a year off.

<comment><USER10> At the time it was python, databases, C, unix and java. A mixture of sys admin and development for online medical records. Part of the reason I left was because I found that I could not cope with how boring my job was. I do not compartmentalize very well. When I returned, I worked for a place that made a music player.

<comment><USER12> cool. how did you find/end up at the "music player" company?

<comment><USER10> I worked with some of the same guys earlier in my career. However, it really was simple serendipity - they happened to be working down the street from where I was living and I ran into them.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> _Still want to code - I don't hate software, but my job has made me realize that I'm really just a mediocre programmer with really good domain knowledge_

This makes me wonder if it is not programming that is the problem but the environment and processes at your work place.

</comment><comment><USER14> _I don't hate software, but my job has made me realize that I'm really just a mediocre programmer with really good domain knowledge_

You seem like a prime candidate for promotion to management or a more analytical role. Is this a possibility or something you can work toward?

<comment><USER15> The irony of Peter Cooper advocating the Peter Principle is not lost on me.

<comment><USER16> Funny, but not as funny as if it were true. PP is when you're competent and get promoted to something you suck at; Peter's suggestion is the other way around. Sorry to nitpick.

<comment><USER17> But isn't it true?

If someone is succeeding as a programmer, that says _nothing_ about how they'll do as a manager. Therefore pushing for that promotion is a good way to wind up getting promoted to something you such at. Which is the Peter Principle at work.

<comment><USER16> Are we failing on ambiguity here? If by "it" you mean "the peter principle", then yes I think it's very true.

But here, by assumption, the programmer is _not_ competent (I doubt this is so, but that was the context) and petercooper's suggestion -- a good one -- was to consider getting promoted into a perhaps _more_ suitable position. That's the inverse of PP.

</comment></comment></comment></comment></comment><comment><USER18> I did the reverse-- I went from majoring in English and teaching high school to embedded systems engineering.

It took a few things-- some aptitude for the field, a lot of determination, some money for a master's degree (over the course of 3 years), and a friend taking a chance on me with a summer internship. After about a year, it was pretty clear that it was going to work. I think I could make a similar switch again if I had the motivation.

It seems the major difference in your case is that you're not sure what you'd rather do, while I had a strong desire for engineering. I would try to figure out where you're headed before you start on the journey.

<comment><USER19> That's a pretty major change. Did you have any knowledge of embedded systems beforehand? Why did you switch? Why not go engineering the first time around?

<comment><USER18> I had approximately no knowledge of embedded systems beforehand. I did well in math in high school and I played around with an Apple II and BASIC as a kid. (Initially, I was just aiming at "engineering" as a broad field; it wasn't until I got further into it that I focused on embedded stuff. My degree was in mechanical engineering, but I took mostly EE classes.)

I switched because I discovered that I love designing and building things. I still love teaching, and I wouldn't be surprised if I did it again.

Why didn't I study engineering the first time? That's a damn good question. The English degree did give me the ability to write reasonably well, but other than that, it was crap.

Mostly, it was just bad luck that I didn't end up in a technical field initially. I went to a liberal arts college and took soul-crushing, thinking- free chemistry and biology classes as a freshman-- that pretty much killed science for me. It should have been obvious, but even as late as my junior year in college, I didn't know that the field of electrical engineering existed. It's kind of a sad story, looking back on it, but at least it ended well.

</comment></comment></comment><comment><USER20> You are having the same problem as mine, except for me I can't stand out to live for a year alone ;)

Your problem is: You are bored from your current job. You have been working for 5 years and it had become a monotonous job. You like coding but you hate your work as a coder.

The solution that I found is: Build something -> Your own -> Not only coding is involved -> unleash the sens of adventure

Take for example a SaaS service. You have to do the design, coding, deal with databases, setup the servers and then test and launch the product. Next is marketing, customer support, may be you'll try Google Adsense in the way, start a blog to enlarge your audience, do some open source work to attract related audiences, travel to x to promote your y to z....

You see? a SaaS (or uISV or any other crap really) will make your salary and also your journey. Start in the side and launch in your vacation, support it in the side until it supports you like your job does and leave. Don't spend your savings as they can be helpful in though times.

You'll get motivation every time you sit at your day to day job desk and feel really bored about it. This boredom (for me) will up lift your working power gauge in the night.

Don't burn yourself, work for 1-2 hours per week-day and 10 hours week-end. You can raise the number of hours, just make sure you enjoy your work. Make light schedules and plans in a way your web/desktop development becomes like an adventure journey. If you are bored read other unrelated-coding/related- project stuff (think marketing, SEO, scaling, culture...)

I'm not sure if this is the correct answer, if so, let just your journey begin!

Hope someday we meet in Dream Land, once each of us achieved his dreams.

<comment><USER21> Problem with typical employee agreements.

 _Build something - > Your own_

is

Build something -> Company owns

</comment></comment><comment><USER22> Any leap into the unknown is very hard, but whatever you do, don't procrastinate on it, the older you get the harder it gets - don't look back in 10 years and wish you'd made the move. Whilst I firmly believe if you really want to do something you can do it at any time, it definitely gets harder as you get older.

Try telling your wife and kids you are going to leave programming and the money you make and start again on something else, it's possible yes, but generally not so easy. Your "support group" of friends is much harder to leave the longer you have had them around. And "aspirations" are generally slightly harder to fulfil as you get older (trainee hairdresser at 25 OK, at 50 it seems a bit weird).

Also don't assume that if you leave you wont be able to step back into it. There is always a demand for good people and unless you are in an extremely limited market you quite possibly will be able to step straight back into where you are.

My wife and I (late 30's) are about to pack up our family and move countries and I'm contemplating what I want to do when I get there so I'm kind of going through the same thing.

</comment><comment><USER23> I did:

<http://www.publicstatic.net/2009/01/sure-change-jobs/>

The biggest adjustment for me was money. I'd gotten so used to buying whatever I wanted (not large things) that I had some money trouble early on.

But I'm back to programming now. I love it.

<comment><USER24> It's a great story, inspiring even, why don't you do an HN post ?

<comment><USER23> Thanks! But it's an old post. :-)

I should probably clean it up, too. Some of the formatting got butchered in a server move.

</comment></comment></comment><comment><USER25> Same story. Different direction.

Worked on Wall Street for almost 20 years. Did everything from quant finance to selling bonds to managing technology project. Left in 2004 (yes, deferred comp was left on the table), moved to Australia to study machine learning and collected a doctorate. Started a biofuel company (long story).

Now, six years later, I'm founding a quant marketing startup. Net result: less salary, more upside, more psychic benefits. Make sure your spouse is up for it and they are willing to grow. If so, you'll be closer otherwise the inevitable stresses may take their toll. Mine ended up getting an MFA and a new career of her own.

Turns out my neighbor in Australia was a senior product developer at Microsoft before he decided to move to an atoll in the Pacific and then get a biology degree. He used to jokingly accuse me of copying him. (Typical Microsoftie.)

I think the bottom line is that mastery is not enough for some people. The 21st century midlife crisis cannot be cured with a new Porsche. You need another mountain to climb.

</comment><comment><USER26> "Oh, you hate your job? Why didn't you say so? There's a support group for that. It's called EVERYBODY, and they meet at the bar."" -George Carlin

<comment><USER27> This is just a joke, I wouldn't take it seriously. Do you really think Carlin hated _his_ job?

<comment><USER28> Yes, I bet there were times that he did. Especially before he was "George Carlin, world famous comedian" and was just some guy trying to land enough gigs to feed himself.

<comment><USER27> Maybe. It's just as possible he always loved being a comedian, even when it was hard to find work. The point is that he found a job he loved. No one should live under the assumption that everyone hates their job because of a joke.

<comment><USER29> Really? From what I know about Carlin, he was onto comedy for at least >3 years before he started getting some attention. Before that it was just a job that barely kept his expenses going. And I am pretty sure that was not the kind of world we live in. Becoming famous enough took time back in his time.

I am pretty damn sure there must have been days he would have hated his "job" as a comedian, because it didn't look like it was going anywhere. And remember, this was the era when fighter pilots and airforce people were considered the coolest ones, and he was kicked out before even completing his Air Force enlistment.

So, I guess it would be safe to say, he had doubts about himself, and he was trying to explore what he was meant to do. And I think we can agree, there must have been days when he hated his "job" as a comedian, but just HAD to keep going.

Just because you love your job, doesn't mean you are not going to hate/ don't care about it anytime in future. I don't think Love/Hate are mutually exclusive. At some point, there must be days when they occur intermittently.

<comment><USER30> Bill Hicks' later stage shows make it pretty clear that he hated the job, and Carlin was about as cynical, so I could believe it.

</comment></comment></comment></comment></comment></comment><comment><USER31> I'm going to make an analogy to love. In the beginning, you're attracted to someone mostly because of looks. Then you get to know all the good things (s)he has shared with you. Eventually, the passion flame wanes and you're now able to see her/his ticks and vices. The flaws.

Getting into software development is similar. At first you get excited by your first "hello world", then you find all sorts of cool things that can be done with code. Eventually the passion flame wanes, you discover maintenance, management. The boring stuff.

First, realize that pretty much everything you get into will follow this pattern because everything has good and bad sides. Then ask yourself: are the _bad_ things in filmmaking/SF start-ups more tolerable than the bad things in your current situation? Are the good things in filmmaking/SF startu-ups more enjoyable/rewarding than the good things you currently enjoy?

As far as happiness goes, maximize the amount of time you spend thinking about the good parts of what you have. Write code for a hobby project, use your money to indulge every once in a while. Dream about things you want to do.

Or just take the leap and do them. Then, you'll just have different good things to focus on.

<comment><USER32> Your comment made me think in a different direction.

I had originally gotten in programming, as you said because of the excitement of hacking, "hello world"; it was an intrinsic joy that I had that I derived although extrinsic rewards (striking it rich) was in the back of my head. But it wasn't the extrinsic demands that was driving me day-to-day, otherwise I would have gone into accounting instead of programming.

But it was all of these extrinsic demands that pushed me to climb the corporate ladder, deal with maintenance & management etc. In so doing, I was telling myself that I had to plough through these minutiae to get to my big external validation of climbing the ladder, becoming rich, etc - when in fact, it was my intrinsic motivation that got me to where I was from the get-go. And if getting to the and staying at the top means sacrificing the internal joy for external validations, then it's not worth it.

I used to think that dropping your obligations to the ladder is counterproductive to your career. But not anymore when I spend more rationalizing and calming myself down from all of the angst of writing TPS reports and posturing/covering my ass during meetings. I don't even have anymore energy/time to actually write code. And that's pretty damn counter- productive.

I always have taken a broad definition of hacking and I see this pattern everywhere. You could see playing guitar as having fun creating music & expressing yourself, or memorizing sets & rehearse & network to get your band signed to a huge label. You could see making friends and picking up women as having fun meeting people & expressing yourself, or memorizing sets & rehearse & network to up your social worth, etc.

</comment></comment><comment><USER33> Here on reddit : [http://www.reddit.com/r/IAmA/comments/c1rcu/iama_person_with...](http://www.reddit.com/r/IAmA/comments/c1rcu/iama_person_with_a_cs_degree_that_decided_to_work/)

An ex Googler says he moved from CS to the lumbering industry ! Hope this helps.

<comment><USER21> On some days, when the nonsense of corporate drama (just like WoW, i swear) crops up. I think: Ok, ok, lets just become a janitor/garbage man so the shit that I have to deal with is up front; then spend my evenings working on OSS.

</comment></comment><comment><USER34> I was thinking of doing exactly this years ago. I sold my Infiniti, bought a used station wagon that cost half as much, and was going to put my self through massage school in Ohio with the proceeds.

A consulting job came up in Houston, and I've been "distracted" from this goal ever since.

I am again unemployed, and I too have about a year's worth of float time. The corporate world is pretty egregious at times. Human social dominance mechanisms are necessary for regulating large organizations, but they shouldn't be the primary focus of one's corporate existence. Unfortunately, they are just that for most organizations.

</comment><comment><USER35> Yeah, I did that. In the 2001 recession, after having mad money thrown at me in the 90's, reality hit and I realized I'm really bad at time and scope management. I spent a couple of years realizing this; in 2003 I decided to focus on one of my clients, do all the programming I could on a particular project to make it interesting to myself, and ended up qualifying for EIC.

In 2004 I got into technical translation, and by 2008 I'd built up the clientele to make considerably more money at it than I ever did with contract programming - plus no scope questions, no need to codify specifications and requirements, no temptation to "drill down and do it right", no debugging, no nothing - just give me a document, I count the words, I translate it, I bill you, you pay me. Done.

I still code - there aren't many translators who can code their way out of a paper bag, of course, so scripting skills come in handy. And I'm slowly developing my own language/programming platform the way I want to. But when I think of getting back into programming for pay, and realize that I suck at programming management and thus would fail again? I stick with translation.

I wouldn't mind working with a technical startup as the coder. But at this stage in my life I'm too risk-averse (kids, orthodontia, college coming up) to risk much on a roll of the startup dice, so I wouldn't be able to devote the focus to it that it would require. But there's no way I'd go back to just slinging code for hourly wages.

</comment><comment><USER36> I wrote code for the military for 3 years after high school. Writing code for a living took what was my most enjoyable hobby at the time and turned it into a chore. I lost all of my love for it.

So, I abandoned code and became an automotive mechanic. That's a fucking leap, let me tell you. Seven years later, my body was wrecked from arthritis I picked up in the Marines, so I got out of the automotive industry (a job I loved) floated for about 6 months then jumped into IT.

I manned a small computer repair store for a year, worked on some art and such then landed a network admin/tech job for the State. Now, here I am, back at computing every day and wishing I still remembered how to code.

I've now put my mind to learning Python and Java and leaving the VB of old behind--

\--but, just the other day I discovered an old application I started in VB5 that got quite close to what I wanted it to do, but not quite. This code is now 10 years old, so I figured SOMEONE wrote it by now. I scoured the web and did not find anything like it. So, now I have an itching to go back through my old code and attempt it all over again. _sigh_

<comment><USER37> If you can, rewrite the application using Python/Java that u are learning (Ruby, if you want to catch up). May be you can refine the idea and do a better job now. I admire your path. Goodluck and keep us posted on your progress.

<comment><USER36> I have thought about trying to re-write it. I obviously do not know much about programming anymore, but this would be a very Windows specific application-- it needs to track files and execute when they are accessed. I'm not sure if that is an option in Java or Python. I've got quite a long time to go before I am up to speed with where I was 9 years ago.

I have pondered writing a blog about it all-- my return to programming, some life hacking stuff and an online comic idea I'd like to launch soon-- but I have always assumed that as a relative nobody, I'd be wasting my time since it would be unlikely that anyone would read it. Maybe I'm being too realist, maybe I just need to do it and fight for subscribers. Maybe I'm just being lazy or afraid of disappointment.

<comment><USER37> File access and monitoring is possible in Java. Using Java will make your app OS independent though. I am not a Python person but I am sure it is possible. It all depends on how much stuff you want to take on, getting back into Programming.

Regarding 'no body cares for my stuff', we all have our traps. Mine is, moving onto the next interesting project. May be there is merit to just doing it. Finishing something, putting something out there and let it do its thing.

</comment></comment></comment></comment><comment><USER38> I sympathize with you. I'm in a similar situation. I've been maintaining CRUD PowerBuilder apps for almost a decade now and I can't stand it anymore. (I'm using "CRUD" as both an acronym and a word.) My current job is soul-killing and makes me want to gouge my eyes out. I'd like to stay in programming, but do something cutting-edge--the complete opposite of the unchallenging legacy programming I'm doing now. I'm in a more difficult situation in that I have a family and lots of expenses, and I imagine switching from being a senior legacy programmer to being a junior programmer in something more cutting-edge would involve a decrease in pay.

If you can afford to be unemployed for a year, that's fantastic! Maybe use that time to learn something cool or work on a fun programming project, to rejuvenate your passion for software development.

</comment><comment><USER39> I've been in the same job for nine years now. Great people, great company, an excellent salary, but it's just gotten old. The work has become repetitive and the big problems have been solved.

So I'm leaving to take a bit of time off and hack on projects of my own. I don't intend to leave programming but I might try and find a new problem domain to work in.

I had an epiphany about this last month: you can't compartmentalize your life. It doesn't work to build your life around a job that bores you - work is too fundamental.

<comment><USER40> I'm in a similar situation - great salary, great people, not so enthused about the company or the work any more. I'm starting to seriously consider taking a sabbatical of some kind too, good luck with yours!

I know a lot of people who can be very happy without caring too much about their job, but that's not the case for me (or you, by the sounds of it).

</comment></comment><comment><USER41> Not seriously. I like coding. But when I don't get to do it . . . I go a little nuts and have had thoughts about just getting out. This is usually related to poor working environment fit for my personality and personal goals. I think it is common, particular for corporate devs, to struggle with these types of feelings.

I have, by accident and plan (lack of knowing the effects), wound up in a similar place to what you describe. More directly, I have developed a marketable, but big corporate-focused skill set (RDBMS, Oracle, MS SQL Server, DB2 . . . ).

This is OK for now, it works for my geographic region, my family, and so far has been low-risk from the "I have a well paying job" perspective, but is completely unsatisfying career-wise from a challenging growth perspective. I've recently turned down one much higher-paying job than I have now and am struggling with a similar decision at this point for another job. My main fear is that the new offer represents "more of the same" and this website, PG's essays, and a number of other sources have poisoned me forever against living in my safe corporate cube in happiness.

Not that this will help how you feel much, but having really good domain knowledge probably has the effect of making you much more valuable than just a "mediocre programmer." Think about those guys that got YC funding, they were _teaching themselves to program_ to implement their idea (can't remember the group, Jessica mentioned them in a Mixergy interview). It's not like they were super-hackers at that point or anything.

If I had your flexibility to quit and move, I'd try to hook up with one of the startups that float around this forum. I read a number of comments that make me think many of them are small with smart people who want hackers looking to push themselves hard and build stuff in a fun way. Could be fun, sounds like you don't need to make much in the way of money, maybe you can just sleep on the floor at the apt office.

</comment><comment><USER42> _"... but anyone ever leave the software world to do something unrelated?"_

Yes, however I don't know how large the number of people who leave programming related jobs is. It would be interesting to know some numbers about this topic.

Anyway, I don't think these numbers really matter for your decision. What matters is how you feel about that. I think the best thing you can do is talking to people who were in a similar situation before deciding what you're going to do next.

Some time ago I posted a quite interesting story here on HN of a game programmer at Electronic Arts who left his job to be a coffee farmer:

<http://www.konaearth.com/Life/2006/060430/>

Worth taking a look.

</comment><comment><USER43> All I know is: 'be wary of releasing changes on Fridays' probably applies to life too.

</comment><comment><USER44> I did, I got so burnt out (see other posts in my profile) that I left. I started a Hardwood flooring business. It was the only way to keep my earnings close to where I was at, at the time. While I loved doing the work, it was a disaster. I had people that would not show up for work, customers that did not like the look of certain boards. Anyway, I came to see that I just traded problem sets and quickly went back to development. Some people get out and are real happy with doing so, for me I took drastic measures for a problem that was simple to resolve. Unfortunatly, it took reflecting back for me to see it.

</comment><comment><USER45> I understand how you feel - I'm going through this right now in fact.

Firstly, I agree with edw519 - Don't think you're bad at what you do because someone may know more, or you just feel that you don't know enough. You can always learn more, but (as is my problem) motivating yourself to learn programming if you don't like programming at the moment is an exercise in futility, and could cause burn-out.

My advice would be to look into industries that sound interesting. Chances are you know a little (or a lot) about quite a few different things / technologies, and that can actually get you quite far in an interview process, especially if you are passionate about it and are willing to learn whatever it takes to be good at it. It's surprising how few people actually "care" in an interview, and from both conducting interviews and being the one interviewed, I've seen a LOT of lackluster applicants. But the passionate ones definitely stand out. And if that is already a topic that you are fascinated by, it becomes very obvious.

Look around, be patient, and try learning about anything and everything that may be interesting on the side.

</comment><comment><USER46> I develope software for 18 years now and left my job 6 years ago when I realized that working the whole day on shitty projects sucks too much. According to Nietzsche, 2/3 of my day wasn't disposable and that made me a slave - regardless of my profession. Today i live with few money, a friend supports me, but the day is mine. Software Development is fun again.

</comment><comment><USER47> I was in your shoes 3 years ago. I thought I would leave software dev entirely if I ever left the company I was working for. Turns out I only hated the company I worked for and loved software dev - went out on my own contracting for several years then recently signed with a fantastic company.

</comment><comment><USER48> My suggestion: keep your job and work hard to become a better programmer in your spare time. Pick a side project that interests you. When the golden handcuffs come off, get the money, and move to SF to join or start a startup. You'll have more funds and be a better developer because of it.

</comment><comment><USER49> I've left the software (well, web) world multiple times under different circumstances. I don't regret any of my hiatuses. Taking detours off your career path gives you a unique experience, a new perspective, and broadens your skill set beyond what you're usually able to pick up in a single industry. The cross-discipline experience (in my case, music vs technology) I've gained is priceless to me on both a personal and professional level and I'm very happy with the decisions I made. Go ahead and veer off the beaten path while you're young, it's only going to get harder the longer you wait. The financial ramifications of my decisions have not set me back very much, if at all, and what I may have lost in money I've more than made up for in lived experiences.

</comment><comment><USER50> The thing I always keep in mind on stuff like this if often times when you take something you love to do and turn it into a career (versus a fun hobby), it seems to takes something away from it.

I think you'd find that to be the case in film-making. I actually studied film-making in college and decided not to pursue it because I had a bad feeling I wasn't going to be the next david lynch, and therefore the reality was I'd be shooting wedding videos for the rest of my life.

I decided it's better to have a career doing something interesting that pays well and pursue my hobbies like making music, or film-making for fun; if they grow beyond fun, great, then I could maybe take steps to make a career of it (aka, perhaps I AM the next david lynch after all...).

</comment><comment><USER51> Go back and do a PhD?

+'s -

       When you finish, you should be pretty marketable
       Pick up a whole new set of research skills
       Support group shouldn't be a problem in a university environment
       Potential for coding if you want to.
       Someone with industry experience will tend to have
       a good idea of what will work in reality

-'s

       You will take a hit money wise until you qualify

You could perhaps look at doing a masters as an intermediate step?

<comment><USER52> Are there attractive, single members of the opposite sex involved with this? If so, just let me know which colleges I should apply to.

<comment><USER53> Depends what you do your PhD in.

Biology probably has the best balance between "attractive" and "sane" you're going to find.

</comment></comment></comment><comment><USER54> Two friends, both developers. One started a video store with his family. Upside, lots of time with the family instead of in a cube. Downside: unstable market, lots of ups and downs.

Other guy started a falafel joint. Never seen a guy look so happy, healthy, totally mellow. Was a developer/manager then VP Software Engineering; now is Dad, cool boss for college students (has record for employee retention in a college town) and Husband he couldn't be before.

</comment><comment><USER55> I've been a programmer for over 10 years now. Back in 2002 I switched careers and became a deputy sheriff. I did it for 3 years before realizing that I had it pretty good in the software industry. I've been back programming now for the last 5 years and have never looked back. With that said, I just finished reading the 4 hour workweek book and am seriously considering taking my family on a 6 month travel adventure.

</comment><comment><USER56> I once knew a guy that sold big iron mainframes for a living before walking away to be a tile contractor/installer.

After telling him about some new system I was working on he responded by saying, "Yeah, that's great. But that's all they'll ever do is get smaller and faster. Where's the satisfaction in that?"

I'm told he did pretty well during the housing boom.

</comment><comment><USER57> Stay in the industry, just stop coding 100% of the time. Project mgt, IT mgt, focus on security, scalability (or other hot topics that really interest _you_ ) and code some on the side. Too much coding will kill your love for it. You need balance.

</comment><comment><USER58> Could you please clarify what exactly is making you unhappy in your current career? True, software engineering ain't for everyone, but you say that you like coding and you're getting paid well. I'm not sure why you "really can't take it anymore."

</comment><comment><USER59> What about it can you "not take anymore"?

If the money's good and you're miserable anyway,the money isn't doing what it promised. Move to SF and join a startup sounds like a good way to inject some excitement. But that goes back to my original question.

<comment><AUTHOR> [http://stackoverflow.com/questions/129508/when-did-you- know-...](http://stackoverflow.com/questions/129508/when-did-you-know-it-was- time-to-leave-your-job)

see the top-rated answer. on top of that, I'm basically not fulfilling my dreams, and I'm sort of preemptively feeling intense regret about my life. but I'm also preemptively regretting making that drastic change and having it ultimately fail me also. I guess I desperately want change, but perversely also deeply fear change.

</comment></comment><comment><USER60> 1\. What do you want to do most, what are you passionate about?

2\. Do that thing, no matter what.

<comment><USER61> To second this, my martial arts instructor used to be a developer, and quit to start doing physical therapy. He loves it and is 100% glad that he changed.

So, just do what you're passionate about, and it will work out. Nothing beats doing what you love 8 hours per day.

</comment></comment><comment><USER62> _I'm really just a mediocre programmer with really good domain knowledge_

I know the feeling. I've struggled with this. Here's the conclusion I've come to: you don't need to be a great programmer to make great products.

<comment><USER62> And I'm assuming that your definition of mediocre is actually "not as good as my idols". This seems common on HN. I've always been a top performer among my coworkers, but it's easy to ignore this and compare yourself only to those most successful.

</comment></comment><comment><USER63> I've quit once for three full years doing nothing but physical work. Moving bits around on a disk is a great way to make money but to build something physical has a lot of satisfaction as well.

<comment><USER21> And it is great exercise for sure, I've been tempted to work at Denny's part time to get paid-exercise. I've also considered construction.

</comment></comment><comment><USER64> I knew a guy at Microsoft who got sick of his dev job and moved to Las Vegas to be a police officer. From what I hear, he's having a ton of fun, but I'm not sure it's less stressful. :)

</comment><comment><USER65> Hey, email me (email is in my profile) ... I've experienced the same kind of thing and have a few of the same ambitions and came up with a solution, perhaps it could work for you too.

</comment><comment><USER52> NO, I did the opposite. I had a successful, promising career dong something totally unrelated, and decided I'd had enough and it was time to do something new. Now I'm a software dev.

</comment><comment><USER66> isn't that the case with most jobs. At first it was fun or even just a hobby, but when you have to do it for a living it's not the same anymore.

Hobby > Study > Work > ugh...

</comment><comment><USER67> Listen to the interview with Tobi from Shopify on Mixergy.com

</comment><comment><USER68> This seems like the wrong place to be asking that. It's like asking who has left the medical business in the doctor's lounge.

<comment><AUTHOR> I know, but I figured the odds were good someone around here used to be a professional programmer, and is now doing something completely different, but still a hobbyist and HN enthusiast. I could be wrong.

<comment><USER35> Existence proof: me.

</comment></comment></comment><comment><USER69> Last I heard one of the original HBase guys quit programming altogether and went into plumbing.</comment>