Tell, don't ask - <AUTHOR> http://robots.thoughtbot.com/post/27572137956/tell-dont-ask <comment><USER2> Example 3 adds a nonsense method, EmailUser#send_to_feed. What does that mean? Email users don't have feeds. If we're going to evangelize OO purity, let's do it right.

        class Post
          def created
            user.post_created(self)
          end

          def send_to_feed(feed)
            feed.send(contents)
          end
        end

        class TwitterUser
          def post_created(post)
            post.send_to_feed(twitter)
          end
        end

        class EmailUser
          def post_created(post)
            # no-op.
          end
        end

The post merely tells its user that it was created. Then the user can decide to do something else. All users know about posts, but only TwitterUser knows about feeds.

Honestly though, if I saw the not-so-good code, I'd leave it alone. It takes a pretty big justification to double the code for the same features.

<comment><USER3> This is all nonsense anyway. There's no such thing as a TwitterUser or an EmailUser. You just have users, some of whom use Twitter, some use email (and may have multiple addresses), and some use both, and they can edit their settings to add and remove accounts and change notification preferences. So it's really has-a rather than is-a.

Adding unnecessary inheritance is far worse than the original problem.

<comment><USER4> I suspect the author is trying to use trivial examples to highlight the pattern. As with everything it's about judgement. If you're going to inherit another type be sure to observe Liskov Substitution Principle, otherwise in avoiding conditionals you're introducing another approach that will lead you towards entropy. That is after all what many of these principles are for isn't it? reduce entropy. Writing the code is easy, maintaining and adding crazy new features from the pesky business is where it gets expensive? Entropy kills apps.

In my experience observing (pragmatically, never dogmatically) OO principles like SOLID reduces entropy. Thus are worth applying.

Personally I prefer polymorphism and null object pattern over conditionals to deal with edge cases, though if you have a leaky abstraction in the first place no principle or pattern is going to save you!

</comment></comment></comment><comment><AUTHOR> For me, this technique is bigger than objects or encapsulation. It's about reusing existing "branch points" that a language gives you (whether it is polymorphism, method dispatch, namespacing) instead of explicit conditionals at a level higher than the language. My general take is that explicit conditionals in a high-level language are a smell. Sometimes they're necessary, but if you tell yourself that they mostly aren't, you tend to end up with cleaner code.

I'm not saying it's possible to avoid conditionals completely, but this article gives several good examples of where it's possible. Someone should put together a similar set of examples in a functional language.

<comment><USER3> It's a poor example of a reasonable technique. Reusing branch points is great. Adding an expensive branch point (inheritance to the User class) to replace a cheap one (if statement) is not a win, particularly when it screws up the model.

Edit: to clarify, by "expensive" I mean expensive in terms of human hours to understand the code, not computer performance. Class hierarchies are much harder to understand than if statements.

<comment><USER5> That depends on what you're optimizing for. If you care about making your code smaller (which reduces the occurrence of bugs), making it more readable, etc., and performance isn't much of an issue, then it probably is a win. If you care about getting maximum performance... well, then, you need to get a good knowledge of the target system's performance characteristics and how language features are implemented in order to decide if it's a win or not (or, y'know, just profile the two options, I guess); it's entirely possible that a string of pointer dereferences might turn out to actually be faster than a conditional branch anyway.

<comment><USER6> > If you care about making your code smaller (which reduces the occurrence of > bugs), making it more readable, etc., and performance isn't much of an > issue, then it probably is a win.

Maintainability over the life of the code is more important than optimizing its present state to the most elegant solution. The code is going to grow, requirements will change, cases will be added not present in the current system.

</comment></comment></comment></comment><comment><USER7> all of those examples look horrible, make debugging harder and implies strong code coupling.

example 1, we're mixing data with UI labels. How do you handle localization ? by coupling your localization code with your user data/behavior ?

example 2 : you're simply coupling the system_monitor with the alarm, while in the worst case, the alarm should be linked to the system_monitor. Now if you want to add a "report_to_government_agency" method, you'd add that inside the code of every single one of your monitors (knowing that you don't want to report a broken light, but it might be a good idea for a melting nuclear core) ? Note that I'm not saying that the first code is good, it's just as bad... Also, the method becomes very poorly named (I want to know if the sensor went back to normal, but every time I query "check_for_overheating", it just rings the alarm and doesn't give me any info back ???)

example 3 is just a poor usage of pseudo inheritance (and an abuse of duck typing). you create a new type of user for every messaging service again ? and if a user uses more than one messaging service, you just create a type for every combination ? Not very scalable nor readable, IMO.

The last example is just as bad. useless inheritance, senseless object. the definition of street_name is wrong. the doc will be around "Street name returns a street name or an error message if there's no street name defined" How do you know if there's no street name, now ?

All those examples basically make all extension harder. They're everything that's wrong with OO. an object is not about one structure that contains data and does everything that can be done with it. An object is about giving organized access to pertinent data and/or pertinent behavior and (potentially) allowing to change them.

</comment><comment><USER8> This is a great little refresher. I recently inherited a codebase of about 3500 lines, 2500 of which are in one class. Not OO.

Incidentally, if this article blew your mind or if you're interested in Smalltalk, I can't recommend this book enough:

[http://www.lulu.com/shop/andres-valloud/a-mentoring- course-o...](http://www.lulu.com/shop/andres-valloud/a-mentoring-course-on- smalltalk/paperback/product-3788890.html)

The author has a radical take on OO in Smalltalk and shows that going to absurd lengths to eliminate if-statements (well, ifTrue: et. al., because it's Smalltalk) can lead to both better readability and better performance.

</comment><comment><USER9> Going down this path seems to put your code at risk for dangerous mixing of concerns, in some cases.

Unit-testing the check_for_overheating inside SystemMonitor looks complicated... The "sound_alarms" call inside probably needs to be a reference to a "Speaker.sound_alarms", right? Why should the SystemMonitor be locked to the API of a Speaker? etc.

<comment><USER10> The 'sound_alarms' call looks more like a local method to me, which could invoke the speaker in a loosely coupled fashion.

The point is more about putting the behavior itself in the object. For unit testing, you'd want to move the individual tests into their own classes, letting the SystemMonitor be the glue that calls them and routes responses to the appropriate system.

<comment><USER9> Your second sentence pretty much hit the nail on the head, as I was reading your first: I'd create a different "controller" object that glues the SystemMonitor and the Speakers together. Then you'd have the neat little "tell, don't ask" in THAT object, instead. (Pretty much what you suggested)

</comment></comment></comment><comment><USER11> Disclaimer: not a Ruby user. I'm confused by example 4. Why would you return a message from either of them? Shouldn't messages in general belong to the view?

        {{ user.address || "No address on file" }}

The "not so good" code is essentially this, but inside a wrapper in view code. What if you need different markup for a missing address, you either stuff it into a method or change the method's return value to nil... and what if only _street_name_ is missing, not the whole address? It looks like a big mess to me.

<comment><USER12> Your example is not functionally equivalent as address is a model instance with many address-related properties. Though I agree with your general premise. This, to me, seems like the Tell, Don't Ask solution:

        class User
          delegate :street_name, to: :address, prefix: true, allow_nil: true
        end

        <%= user.address_street_name || "No street name on file" %>

</comment></comment><comment><USER13> Makes some good points. I can't help but notice, though, that the "good" examples are all _longer_.

It makes me want to design a programming language that makes good code shorter than bad code...

<comment><USER14> With the exception of example 3 (which is possibly a bad example, see the discussion above), this is because of how much code is necessary to tell what's going on, rather than an increase in code size.

Example 1: 5->1: It did get shorter.

Example 2: 5->8: One of the lines is showing a line calling the check_for_overheating method, which wasn't shown in the first example. The other two are declaring the SystemMonitor class, which was declared "off- screen" before.

Example 4: 7->13: Five lines for declaring and defining User.address, which was off-screen before. So it did get a line longer.

</comment></comment><comment><USER15> Ick, breaks command/query separation, the other OO rule that along with tell, don't ask I find to be a hallmark of well coded OO systems.

class SystemMonitor def check_for_overheating if temperature > 100 sound_alarms end end end

</comment><comment><USER16> Also see <http://c2.com/cgi/wiki?TellDontAsk>

</comment><comment><USER17> This has long been one of my favorite methods of using OO code to my advantage; and is one of the main reasons that my code is OO in the first place.

There are many cases where it's easier/lazier to have if-statements.

Going further, you can take the things learned in this article to make your general purpose code potentially faster, as well. For example, if a set of things that must be performed in order; and sometimes some of those steps are missing, instead of performing a null-check, you can have a default no-op case; that way, instead of:

       if(firstAction != null) firstAction();
       if(secondAction != null) secondAction();
       if(thirdAction != null) thirdAction();

in your inner loop, you can have:

       firstAction();
       secondAction();
       thirdAction();

While whenever firstAction, secondAction, thirdAction are set, you can say:

       firstAction = newFirstAction ?? noop;
       // etc.

All in all, I'm glad this sort of knowledge is getting out there. I'm just grateful for my having really, really good CS teachers back in highschool ( I don't remember my college talking about OO as a way of removing if-statements ).

* Users of Java, of course, will just need to write a NoOp instance of their interface to take advantage of this.

<comment><USER18> I'm not clear on how that makes your code more maintainable though. The first case makes it explicit that any of the actions can fail to occur, whereas the second one, on first glance, seems to have all the actions occuring. I, as a newcomer to this code, will almost definitely make that mistake, which will make debugging or maintenance harder.

The only way the second is even -as good- is if I'm constantly holding in my mind the various idioms you've used in the code, in this case that your function pointers are never null but will instead refer to an action that might do nothing. As far as I can tell, this is more work for me, for no gain.

I would love to hear your reasoning why this way of doing it is -better-, as opposed to just -more object oriented- (or -marginally less typing-).

<comment><USER17> I may expand on this later; but, whenever you're going to a new code-base, you're going to have to learn the various idioms that are at work in that code base. This is especially true when you're working with some more complicated languages where no one uses the whole set of it (see: C++).

When I'm writing my code, I personally find that being able to trust what my code is doing to be more readable. In the case I wrote above, more than likely, I would have arrived at that point by first writing whatever the first action was; and then coming to know that there could be two different actions that could have taken place (causing a method call/inheritance to occur) and then I realized that sometimes, nothing might happen. Now we have a nothing case. The nothing case did not negatively effect my code flow. I am not 100% sure I would write code like I had above in the first place, it would grow to that state organically; but, the advantage of trust later on, was worth noting.

I originally heard this concept a long, long, long time ago; and one of the interesting selling points that the person that told me it was that code could be faster run if it had no if-statements, reason being branching and branch prediction forces the processor to rewind; whereas a guaranteed jump is potentially less expensive, especially if the code is in the cache. Of course, this would be a premature optimization, but if the code occurred in the inner- most loop, there may be some gains to be had that otherwise wouldn't be.

I suppose, for me, it looks cleaner when you're dealing with larger projects. That said, as I contemplate it further, I could certainly see where it would slip up some people, especially newcomers to my code. This sort of creativity would probably primarily spring up in organic/fluid code where OO paradigms are already in place.

Thanks for making me think on this further :)

<comment><USER18> It's an interesting point about the speed. In this case, since it's just a function pointer, there's no polymorphic overhead, so avoiding branches is a no-brainer.

On the other hand, if you were actually extending a class to make a DoNothingClass version, then the overhead of dynamic binding plus the function call would make it somewhat slower (branch prediction on a NULL comparison will cost at most 5 clock cycles in a single-thread pipeline, or none if you predict right) on those checks where the DoNothingClass is the one you find. For instance, if you had a sparse array of Class* and wanted to iterate over them, the NULL check would probably be more efficient than pointers to a singleton NullClass, especially since branch prediction will start correctly predicting NULLs more often.

So, you know, trade-offs.

<comment><USER17> "will cost at most 5 clock cycles in a single-thread pipeline"

Being a little pedantic here: you can't safely say this part without knowing which kind of branch predictions the processor uses; and, more importantly, how deep the branch prediction can go. There are some processors that will branch predict once ... and then again, and again and again. The first one they get wrong, they have to roll back to that first one. But then, you're right. The more times that single method is called, depending on the implementation of branch prediction, the more often it's going to be right, and so as long as those values aren't changing often (I don't see why they would in the case we're trying to suggest), it may eventually fade into nothing.

Needs moar testing!

</comment></comment></comment></comment></comment><comment><USER19> I liked the first example, but then it felt too preachy; OOP isn't necessarily the correct way to do things.

I really like the clean design of the site though, very fresh imo.

</comment><comment><USER20> Awesome! This is think kind of article I love to see on HN.

</comment><comment><USER21> Refactoring: [http://www.amazon.com/Refactoring-Improving-Design- Existing-...](http://www.amazon.com/Refactoring-Improving-Design-Existing- Code/dp/0201485672/)

Read it. Learn it. Love it. Make it a habit that is so ingrained you do it automatically.

Extract method: do it reflexively.

</comment><comment><USER22> I'm not trying to be elitist or superior, but I can't understand why this has spent such a long time on the front page. Shouldn't the content of the article be considered pretty basic knowledge at this stage of OO? Deferring implementation specifics using polymorphism was one of the first things I learned about OO when I was introduced to it (via C++) around 1992. It was definitely 'aha' worthy then, when the vast majority of commercial development was procedural, but these days? Shouldn't it be considered a basic tool in most devs' repertoire?

<comment><AUTHOR> It should be, but I can assure you that it's not. Also, I think this has much less to do with OO than with conditionals at large.

</comment></comment><comment><USER23> If you're interested in this kind of thing I highly recommend Avdi's Objects on Rails book (it's free) and Destroy All Software's screencast collection.

</comment><comment><USER24> Cool, I haven't heard of this before; I will think about it. Presumably, an exception would be 'view' type objects in an MVC setup?

<comment><USER25> I apply this principle to view objects as well. Can you give an example of something you think should be excepted?

<comment><USER24> I'm still thinking this through, here's what I came up with:

If there's an on/off button to show additional information on the screen, it would seem weird to me to have the button (view) try and display the additional settings. The view has no idea what kind of environment it is in, how does it know if it can display the information without moving other things around. But a controller object managing all the views on the screen does. This also avoids subclassing or adding methods to the view.

</comment></comment></comment><comment><USER26> The first example isn't a good one. You don't want to have the user class responsible for returning the welcome message.

</comment><comment><USER10> Excellent. As a self-taught hacker, I always felt like I was missing something about OO, because it's introduced with an analogy to real world objects, while glossing over the more subtle contracts that programming objects have with each other. Seems like we need a more developed vocabulary to express these things.

<comment><USER27> I first heard "Tell don't ask" in relation to Smalltalk.

If you want a developed vocabulary, Smalltalk is where you find it (and it's been there for thirty-odd years).

<comment><USER20> What would you recommend? Smalltalk or Pharo?

<comment><USER27> I'd recommend "The Art and Science of Smalltalk" by Simon Lewis.

Because it's so old, Smalltalk does things very differently to other development environments.

The GUI is strange by today's standards (Smalltalk was why Xerox developed the GUI - you can see how much extra work Apple did to make the windows/icons/menus that we use today).

And it uses an image (which is sort of like developing in a VM, and then copying that VM to another machine to deploy).

So diving straight into a Smalltalk may leave you a bit lost - whereas the book is quite a good primer on OOP in general and where those OO patterns came from (whether Squeak, Pharo, GNU or one of the big expensive implementations).

</comment></comment></comment></comment><comment><USER15> Relatedly, a long, long time ago I found Allan Holub's PPT Everything You Know is Wrong quite good: [http://ebookbrowse.com/everything-you-know-is-wrong- pdf-d281...](http://ebookbrowse.com/everything-you-know-is-wrong- pdf-d281291032)

</comment><comment><USER28> Wow, short article, but huge impact... I'm gonna start doing this... Makes so much more sense. Thank you.

</comment><comment><USER29> The example is too simple to describe this design.

</comment><comment><USER30> examples could be much better..

</comment><comment><USER31> This principle applies much more broadly than just to programming with objects, for example it's an excellent way to deal with bureaucracies or managers who don't always read their email.</comment>


Snarky, profane ACLU brief supports John Oliver against coal company CEO - <AUTHOR> https://www.documentcloud.org/documents/3911409-Wvnd-19902323086.html <comment><USER2> Yep, it is snarky and packed with great one liners but one of my favorites is on pg. 1, " because Plaintiffs' delicate sensibilities were offended, they clutched their pearls and filed this suit."

The "you can't sue people for being mean to you, Bob" sums up the brief. This is evidence that not all legal briefs are dry.

</comment><comment><USER3> Pg 7. "truth is an absolute defense to a claim of defamation" proceeded by a picture of a side by side comparison between Dr Evil and Bob.

Hilarious.</comment>


Ask HN: What should I do if I feel burnt out? - <AUTHOR> I'm a 23 year old developer working for a medium size startup. I made the switch to my current employer about four months ago from a corporate job. While I enjoyed the move for the first three months or so, I do not feel the same now.
The reason is that recently one of "star" developers at my current employer was poached by another company. As  a result, most of his work (which I had no clue of) came on my shoulders. The code that I inherited is unidiomatic and written in a way that only the author could understand. And now, since I "own" the code, I've been putting extra hours and working on it as much as 15 hours a day to understand it and make fixes (which has become my day job). Despite of all this, I've failed to deliver on most deadlines (as the managers had higher expectations from me). To add to all of this, I've been diagnosed with hypertension, that gets worse with stress.
Given this, should I risk being labelled incompetent, by telling my stakeholders about my problems or should I put in the long hours needed to get stuff done (as that's what people in startups do). <comment><USER2> _Given this, should I risk being labelled incompetent, by telling my stakeholders about my problems or should I put in the long hours needed to get stuff done (as that 's what people in startups do)._

Gaaaaaaaaaaah.

Sorry, that was just my scream of frustration about a world which doesn't make this answer obvious.

You're an adult now. Go to manager; say that you've inherited a code base written by a more senior developer which has a substantial amount of technical debt in it and you'll need time to get up to speed on it. Work together to get a better understanding of when the milestones will be shipped successfully. (Unobvious-to-younguns true fact about managing: managers often need predictability a lot more than they need speed.)

Do not work 15 hour days to try to grok the code better. If you model your manager as a heartless automaton (and he isn't!), he'd heartlessly prefer you to be resting at home rather than in the hospital, since only one of those means you'll be filing TPS reports tomorrow.

Do not attempt to sprint your way out a scheduling issue. The business will _always_ be capable of finding another catastrophe. You know how there are a herd of cows or a murder of crows? There's a startup of catastrophes. Companies/individuals/teams which develop crunch cultures _never stop crunching_. They ship whatever the blocked milestone was -- late, of course, because crunching very rarely actually speeds shipping -- and then promptly identify a new milestone to crunch towards.

It is not the job of 23 year old developers to insulate the business from the predictable consequences of the actions of more senior employees. If your manager feels differently, there are many saner managers available. That's a pretty radical step, but choosing burnout is a _much worse_ step. Burnout is _not fun_. You wouldn't choose to develop adult-onset diabetes because it would avoid a difficult conversation at work. Don't choose burnout, either.

<comment><USER3> > Do not work 15 hour days to try to grok the code better.

... because that's less likely to succeed than using 8 hours a day.

Even if you neglect the long-term eventuality of burnout working more hours in a creative/intellectual job does not result in more work being done: it will nearly always result in less.

If you can't get the work done in your normal working hours it means that the deadline is actually impossible. Some problems cannot be solved by throwing numbers at them; your manager has to throw planning at them.

<comment><USER4> In many companies:

\- saying "it's going to take me X months because of the technical debt" is not an acceptable answer to the manager;

\- working 15 hour days and taking X months more than the deadline is rewarded particularly if every diff is recorded in some kind of micromanagement tool used by the manager, for being "team spirit" even and especially with lower productivity.

Since not everybody can hop jobs easily, a successful way to survive in such a situation CAN be to just pretend to work long hours, put in the face time, enthusiastically play along with the micromanagement game and hope the job market will improve before the company goes under or the department is disciplined for its lack of productivity, and before this situation takes too deep a toll on your intellectual ability and happiness. The key is continuous small, trackable deliverables, and focusing on additive changes rather than improving the existing codebase.

It's important not to think about karma as such managers get promoted out of the way before their results catch up with them, and you'll just get more miserable as you watch them fly higher and higher on their column of hot air.

/rant

<comment><USER3> > Since not everybody can hop jobs easily

That's a reality I forgot about. Your advice is far better than mine is for someone just starting out.

<comment><USER5> No, it's not. The damage of burnout is real. It can damage peoples' physical health, and also their marriages/relationships.

Then there's "faking". That damages your soul, your heart, your inner person. Have integrity. Don't fake.

So, if he/she has to put in the insane hours to prevent being laid off, he/she should be job hunting for a sane situation, starting today.

</comment></comment></comment></comment></comment><comment><USER6> _should I risk being labelled incompetent, by telling my stakeholders about my problems or should I put in the long hours needed to get stuff done_

Neither.

You should out the "star" and give your management the opportunity to solve their problem.

What's the problem with the "star"? "Getting stuff done" is only half our job. The other half is "keeping things done". You're probably the first one to discover his charade. (Yes it's a charade if you're hitting deadlines while creating techincal debt for everyone else!)

What's management's problem? They understand "getting stuff done" but obviously don't understand "keeping stuff done". They have failed by allowing all this technical debt to be accumulated. Where's the due diligence? The peer review? The code review vs. standards? The regression testing? They need to get their house in order and you're just the person with just the right ammunition to help them get started.

Your best option is also the right thing to do: fix the problem long term and give everyone else (management) the best opportunity to do their jobs properly. Anything less is bad for everyone, especially yourself. Remember, it's a marathon, not a sprint.

What you see as lemons is actually a rare enterprise opportunity (at age 23!) to make lemonade. Take advantage and become the real "star".

</comment><comment><USER7> Please, make sure you are eating healthy, exercising, taking regular breaks, and sleeping. Burnout manifests itself much quicker and continues to linger even longer when our health is neglected.

Start a conversation with your manager and a HR representative immediately. Burnt out engineers are a sign of bigger problems, and I guarantee that you are not the only one in that situation. If your company is worth working for, this type of conversation is welcomed.

Some context: my most recent experience with burnout was about a year ago. A result of 8 sequential 130+ hour weeks. Around week 6 or 7, my code was utter garbage (more than usual), my attitude towards the project was awful and I was setting a bad example to my peers & team. In retrospect, I was probably hurting the company more than I was helping.

Today, those 20 hour days with 2 to 4 hours of sleep screwed with my memory retention and general ability to focus. Wish I could take it back and do it differently.

For me the burnout cycle ended after several conversations with the company's founders. They were very clear that employee health is paramount to the company's success and continue to work on mitigating the root causes of engineer burnout.

<comment><USER8> _eating healthy, exercising, taking regular breaks, and sleeping_

Once someone's reached a 15 hour workday, that's pretty much impossible. Normalising hours to 8 has absolutely got to be the first step.

<comment><USER7> Selecting a somewhat arbitrary number of hours without establishing personal priorities for self well-being only fosters a more stressful situation that increases the probability for relapse.

(disclaimer: what works for one person may not work for everyone)

Nutrition, exercise, regular breaks, and a reasonable amount of sleep are what I consider the bare minimum and should be implemented with a thought out plan.

When faced with the 15 hour week. I start by creating a time budget, allocating my personal priorities first.

Here is a simplified example:

Sleep: 6 hours Exercise: 1 hour Meals: 30mins x 4 = 2 hours Breaks: 8*15min = 2 hours \</comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>- Total personal hours: 11 hours

Remaining work hours: 13 hours /day

1 Day off every week to run personal errands, shopping, etc.

For me, this budget yields a 6 day work week totaling close to 80 working hours ensuring a break roughly every hour and 4 nutrient dense smaller meals.

Hope this helps.

</comment><comment><USER9> You will do permanent damage to your brain if you choose the stress/burn down way!

Besides all the research pointing to that fact, I myself has burned myself into smitherines from stress and a toxic working enviroment. It took me two (2) years after my burnout to be able to work more than 2-3 hours a day and 4-5 years before I could work 8 hours a day for a week!

The brain is plastic, this means that it changes from stress and once you have overloaded it, it becomes more sensitive!

It's like breaking a bone - even though it grows back together, it will always be weaker.

<comment><USER10> Not disagreeing with the general point, but aren't bones _stronger_ after a break? I thought that was the whole point of martial artist's punching hard stuff.

That said, I also have burned out before and it is _not_ fun. While I didn't have the long-lasting negative effects you describe, I have grown a strong reluctance towards working "long hours" on other people's ideas.

<comment><USER11> > Not disagreeing with the general point, but aren't bones stronger after a > break? I thought that was the whole point of martial artist's punching hard > stuff.

They don't break the bones, but merely introduce microfractures.

</comment></comment></comment><comment><USER12> Well you already know where it leads. I think if you have a smart manager, a good long talk might be in order; explain that if you feel the urge to bolt and find another job, it's probably not a good idea for anyone involved. Explain that as much as you are ok with 'pressure' there is a pressure point where it breaks, and you feel it's not far off...

If you don't have a smart manager, well, take off QUICK. I had a burnout in 2006, took me the best part of a year to recover, and that was actually quite hard.

<comment><USER13> Talk...Talk to your manager, friends, family and other support system. This will give you different view points on how the current situation can be handled. Solicit help. Do not always try to brazen through these issues alone.

</comment></comment><comment><USER14> You're too young to be going through this anxiety. That'll come later in the "years of responsibility". Take all the things you worry most about in your situation and assume they are true. Assuming they're true, then what? From that answer do the same thing until you can't cone to any more negative outcomes. You'll be surprised what you learn about your mind and the true cause of your stress (not so much the 15 hour days). At the end of the day, you're 23 and have the world by the balls. Open your mouth and let your superiors know that it's too much for one person. Worst case scenario, you walked out of there with a valuable lesson and probably working in a better environment somewhere else. Keep your head up and blood pressure down. :)

</comment><comment><USER15> > should I risk being labelled incompetent

That depends on if you _are_ incompetent or not.

No, seriously - it's _very_ hard to judge the level of your own skills, both technical and others. Try to find a senior dev who is not a total asshole and go ask them. If they worked with you earlier, it's all the better, but probably any experienced dev (who's not an asshole) will do. Just tell them honestly what you're doing, what you're struggling with, what you did in your previous work, things like this. This should be enough for any decent senior to tell you how skilled - relatively to others - you are. Would it be easy to change the job? Which kind of development (embedded, mobile, ...?) would be the most natural for you to pick up? What would you need to learn to change your domain to something else than your current one? Just have a little chat and you'll at least know your options much better.

And also, if you're unable to find a well-meaning, non-asshole senior dev in your company you should be out of there already!

</comment><comment><USER16> Don't burn out. Tell them, in very frank terms, about the technical debt and demand a reasonable timeline. If they give you pushback, tell them to do it themselves or fuck off. You don't have to use those words, but you may have to.

The fact is, you're putting in 15 hour days to give them a chance to get extremely wealthy. You deserve to do so in a way that lets you live a life you are happy with. Always a relevant link [http://www.jwz.org/blog/2011/11/watch- a-vc-use-my-name-to-se...](http://www.jwz.org/blog/2011/11/watch-a-vc-use-my- name-to-sell-a-con/)

Employment in a startup can be very rewarding, but it needs to be mutually beneficial. If you're getting taken advantage of, bite back. A good friend doesn't just praise you, they criticize you when you're failing, and in this situation the company is failing you, as both an employee and a human.

Good luck.

</comment><comment><USER17> You need to talk to your manager, it's their job to understand your situation and help you (and therefore the business) to succeed. There is a possibility they won't get that in which case you need to look for a new job (that won't be hard). Pushing yourself too hard can be an issue, doing it with a backing track of stress around others impressions of your competence is a recipe for disaster.

There should be a way out of this which will leave you, your manager and your coworkers happy and productive and your company successful as a result. Focus on that belief when you plan to talk to your manager, and try to ignore any fear you have about negative impressions they may have of you. And take a break as soon as possible.

</comment><comment><USER18> Stop working 15 hour days. That's just stupid and grossly counter-productive. Work your 8 hours, then go home and don't think about it.

Your brain needs time to absorb, process, and synthesize. It can't do that if you're trying to force-feed it new information faster than it can handle.

Take some time to write a couple tests against the code, to make some small refactorings, etc. If you still feel overwhelmed or underwater, talk with your manager and just tell them the code is a pile of crap (if it really is). They don't want to hear it, but they might cut you some slack.

</comment><comment><USER19> Marathon stretches of dev time can be very productive.

You know that feeling when you leave the office at 11pm having finally sorted out that bug? Nothing beats that feeling, you sleep VERY well that night.

You know your limits better than anyone. Pull a few late ones, but not too many. If it still seems too much work or too hard, then tell stakeholders.

<comment><USER20> I get that sense when I figure out how to make something new. I get a VERY different sense after getting to the bottom of something and finding out that someone was "moving fast" and that I wasted hours because some easily avoidable mistake was made. Busting your ass to build stuff makes you feel kinda accomplished, busting your ass because someone managed to use your time as collateral to pay for their convenience makes you feel kinda dicked over.

</comment></comment><comment><USER21> You're not incompetent. No one in this world is incompetent. Just put that in your mind.

Communicate with your management. Explain the situation. Be on the point. Don't over explain.

Things will work out. If the management doesn't care, it's not the company you should be working for.

</comment><comment><USER22> Take a 1-2 week vacation.

<comment><USER15> Much too little time in my experience. Two weeks is just enough to start thinking that maybe not everything is shit, but not enough to really believe it. When you get back to work in this state of mind, you quickly realize that indeed, everything _is_ shit, and you're much worse off than before.

1-2 weeks of vacation is what "normally" suffices, i.e., what "normal" people do. "Normal" people as contrasted with "burned out" or "on the road to burnout" people. It's not going to be enough for the latter group to do what is normally done: if it were enough, they wouldn't be burned out in the first place.</comment></comment>