You fired your top talent. I hope you're happy - <AUTHOR> https://medium.com/@deusexmachina667/you-fired-your-top-talent-i-hope-youre-happy-cf57c41183dd <comment><USER2> There are quite a few places like this out there, typically technology has a muted role in decisions in these organizations, quality takes a backseat for the crunch for the next meeting demo, ad infinitum.

A smell of these types of places is they always blame the developers that just left, almost like a scapegoat or two minutes of hate rally. Another smell is estimation is rarely respected i.e. if you say it will take a month they should expect it to take that long or even twice as long as the programmer estimate, but at places like this, about halfway through they say it has to be done in a few days for a _very important meeting or deal_ , if it is that important you want a solid product not a one off.

As a developer you also need to manage balance and workload. Consistent work discipline and good sleep/health are important. Take on challenges but be sure each project is a focus and you aren't spreading yourself too thin, work quality goes down when you don't have some buffer. A good developer would never design a system that is constantly pegged, don't do the same to your schedule/self as that is a single point of failure.

<comment><USER3> Wow, that exactly describes my company.

Our group ignores the ops stuff necessary to keep our product up and running to keep pushing out garbage for the next big demo. Most of our product is not working multiple days out of the month.

Some MBA guy with ambition learned enough technical skills to keep things up and running with some help from me.

Boss goes to MBA guy to keep things up and running and considers the problem "solved". MBA guy is running himself ragged by logging on after hours and screwing around with data files just to keep things running, then doing the same admin BS all day.

After MBA guy is let go, he is badmouthed for coming up with an unsustainable solution. All future admin work is explained as being necessary only because of him.

Eventually we had our "launch" and our PM did the "big presentation" to our company leadership. After everyone started to realize our product was garbage and we had boatloads of promises we could never keep, she just jumped ship.

I would have considered the whole thing a joke except it ruined my health and relationships for several months.

</comment></comment><comment><USER4> I see so many sides to this

-I've been a Rick, stayed at a company for nine years, knew where the bodies were buried because I buried most of them myself and became more disenchanted year after year which caused my attitude to get worse and worse. They wouldn't fire me but they also wouldn't promote me and give me raises - causing a horrible cycle.

I woke up one day 8 years later in 2008 and making only 10,000 more than I had made in 1999 as the raises were abysmal and the bonuses got cut realizing that I wasn't competitive.

9 years, four companies, and a lot of humbly studying and learning from people a lot younger than I am, I'm finally in a position that I want to be in as the software developer lead for the company.

I saw myself becoming the bottleneck and working crazy hours for the first 5 or 6 months. I had to put a stop to it. I sat down with my manager, hired three more people. I now insist that everyone be responsible for making sure their work gets all the way to production, everyone does there own devops work, documentation is part of the "definition of done". I let them solve their own problems even if I know I could solve it faster.

I'm training the team not to be dependent on me.

When it comes to meetings, each developer is responsible for chasing detailed requirements when there are gaps.

My responsibility is to hire, train, and to mentor. I will do the most critical pieces of the architecture that is a base for everything else. I also enforce a 40-45 hour work week. If you want to learn on your own that's fine but no one should put in crazy hours. We don't want to set that expectation.

<comment><USER5> When I read the original article I was immediately curious how Rick would've written about this, and whether he was really as bad as he sounded, because I also have been, at least, a semi-Rick. Or at least I can imagine someone writing about me in a way similar to this.

There's a lot I could say about my experience, but it boils down to a combination of bad practices/behavior on both sides (that I learned from immensely), broader circumstances, as well as a bad fit between me and my direct superior(s) or the nature of the company. I think the latter is often underestimated.

I believe that the 'true' story of bad employee/employer is often a lot more like a romantic relationship than we care to admit. And while my impression is that Rick was more at fault in this situation, I'd say that just like a romantic relationship, the best lessons to draw from these events are not the blame-game ones.

(of course, maybe that says more about my romantic entanglements than about work hierarchies...)

EDIT: tangentially related, but I just realized that one of the few ways in which I feel I can say I've 'matured' on my path to 'adulthood', is having experienced multiple sides of, in essence, the same situations. It makes empathy and productive solutions so much easier, even if not always in the moment.

This kerfuffle is a good reminder for me to keep an eye out for these types of lessons and to avoid reflexively looking for someone or something to blame.

<comment><USER6> Having an entire product rest on your shoulders sucks and emotionally drains you rather quickly. In my case it was a startup with a technology I created on the side that became the main business and eventually became the sole earner for a company whose other business had already been dwindling.

At the time there were maybe half a dozen people in the country that even worked in this particular niche. If I left the company it would likely go down, and the CEO kept telling me how many people would lose work if I left. And the pressure and responsibility kept growing and growing. And the sales people, who made up half of the staff, kept getting more and more antagonistic, as I couldn't meet their constantly larger expectations, which were often technically impossible (like sci-fi movie level). This situation lasted for over a year, culminating in a huge blowout between the CEO and I when I left.

I became a Rick real fast. I still feel like shit for being a Rick, and it's taken years for me to move that experience out of my "work baggage".

</comment></comment></comment><comment><USER7> While I can agree there are 'real' rockstar developers that act like the original article mentions, I don't think whether Rick was or wasn't one of them is what matters here. What matters most here is how management dealt with him and their lack of responsibility for Rick's work for the last two years(!) and the end as their result.

Other industries seem to get this better than ours. I've worked in quite a few places that assign too many projects or tasks to key developers and then reprimand them for lack of quality or quantity, which ever you will inevitably buckle under first and it's never the manager's fault for assigning too many tickets or not prioritising their tasks correctly (we're not mind readers) but yet it's always the developers fault for the perceived lack of skill or lack of effort. Don't get me started on the arbitrarily shifting release dates that correlate with buggy releases that we developers get angry emails about. Maybe I've worked at badly managed busineses, or hey, maybe I'm just a bad developer, but this seems like the normal to me.

But if you're managing someone and they fuck up, it's also your responsibility because you were meant to be managing them. That was your job. Even if Rick was told to stop working, take a break, and he didn't it's still not up to him, it's up to the manager to decide what's best for Rick and best for the project.

<comment><USER8> > _Don 't get me started on the arbitrarily shifting release dates that > correlate with buggy releases that we developers get angry emails about._

I'm willing to bet that it likely causation in a majority of cases. I've been there. Business comes back with a list of wishes for the quarter. We're asked about the features as a whole, and I'm already on the fence about whether it can actually get done.

We start getting granular with the stories. By the end of the first sprint's estimations, we've definitively said, "There is no way we can finish all of these by the end of the quarter." That's taken back to upper management, and the whip is cracked. Too bad.

Sprint has started, and instead of a quarterly wish list, we now have hard, immobile release dates for different feature sets that don't give enough time. Some people are working long hours, and some of use are sticking to our 40 and done. The features are released as wished. The production defect count increases, and the production team grumbles.

I assume we'll repeat this until the clients get sick of shoddy workmanship and outages.

<comment><USER7> Working overtime without some sort of commiseration should be illegal, yet it is typically expected in a lot of salaried work. Even my local groceries makes their workers spend 10 minutes cleaning up before close, 'off the clock'. Game studios are notorious for the crunch at the end of a projects life cycle because of the random off the cuff date a publisher needs to fill up a void in their yearly lineup or quarter.

The thing is they don't explicitly say 'work over time' they say 'this feature needs to be complete and working by Monday or else' What does management think the developer will do, pull it out of our behind? Reminds me of Steve Jobs, actually.

I once had my boss explain to me if these features don't get completed before the end of the month, he will lose his house. I had already previously told him that it's impossible and had to explain we will need to compromise to reach that date. We released 1 month late but the software has a lot of issues and I'm now blamed for this as the lead developer of only two programmers. I worked 12 hour days 6 days a week for 1 month and he wanted me to work more. He still has his house.

It's a zero sum game. Developers only have so much time in a week and the more you chip at sleep and rest/play time, the more it's going to cost the developer's health and the project's cost.

It's frustrating because I'm just a developer (mostly contractor to boot) and yet I feel like I have valuable constructive criticism that would benefit management and the productivity of the project on the whole if they adapted it. You can rarely pull that off tastefully. Maybe I'm wrong, maybe these things exist for a good reason and I'm seeing this differently because I'm not in management so I have some confirmation bias. That's possible, but I've experienced the exact same scenario as you and it always seems harmful for the developer and harmful for the project.

<comment><USER3> I'm new in this industry, but based on my life, the experience of some close friends, and anecdotes like this, my impression is that you need enough career security and cash savings that you can just ignore stupid requests from your boss and not care about the fallout. Of course that is probably unsustainable outside of entry level jobs, so I am sort of convinced that I should have a 6-10 year plan to exit it

<comment><USER7> That's an interesting way of thinking about it. I'm not very assertive, so perhaps If I stood up to management a bit more everyone would be better for it anyway. Although it's easier to stand up to your boss when it falls under your domain (technology), but when it's their domain (managing people) it's harder to be assertive.

Also what happens when it just becomes a self fulfilling prophecy? Regardless, if you experience terrible management you should probably be finding another job anyway.

</comment></comment></comment></comment></comment><comment><USER9> Yeah, wow.

I mean, Rick's a dick, no doubt. But much like Frankenstein's monster, it's incredibly easy to see who had a hand in transforming Rick into what he became. It's hard to read the original article and not see several large "where the hell was management" red flags:

> Any time there was a particularly challenging problem, Rick would handle it.

That's a _management failure_ , and a particularly egregious one that I see new or overly passive managers make. How do you expect one person not to have all of your domain knowledge if they're solving all of the challenging problems?

Fixing this doesn't even involve being super confrontational:

"I'll fix <database issue 123>." "Hey, Rick, you're already working on XYZ and I want Summer to get some experience working with our database system, so I'd like for her to do it."

> First, he created a cult of dependence.

Because management idly sat by and let him do that. People want to feel irreplaceable and like they're exceptional. One way to do that is to create this cult of dependence. Management's job is to step in and re-assure Rick that he's a valued member of the team while also directly confronting this cult of dependence.

We do this all the time at my job, and we don't even do it using complete thoughts. We just say "bus factor" and everyone understands why one person can't be responsible all the time for something (or in this case, everything).

> Team members didn't want to speak up and offer their own ideas because he > always berated them for it.

Holy shit, you didn't torch his ass for berating people in meetings? Are there even managers at this company?

This, to me, is the worst failure. Either management is ignorant of the berating (bad) or they silently tolerated it (even worse).

I really hope the managers at that company are taking a long hard look in the mirror and doing a post-mortem on what went wrong with Rick. I suspect they're not, and attributing it to one bad employee, but I can hope.

<comment><USER10> > _I mean, Rick 's a dick, no doubt._

"No doubt" a real person is a dick, because of a single-sourced account from those who fired him, which even at that, leaves the question of their own failures wide open?

<comment><USER9> Ehhh sorry, saying things like "I'm Albert Einstein and you're all just fucking monkeys scratching in the dirt" doesn't strike me as the speech of someone who's particularly nice.

Most people (at least in my experience, you know, the one who's making the subjective judgement about him being a dick) can be angry without saying something pretentiously mean like that.

It's ok for the conclusion here to be, "Rick's an asshole who should've been fired but management fucked up pretty badly." Situations don't have to be binary with only one party at fault.

EDIT: Let's also not forget the accounts of Rick supposedly berating people in meetings. If multiple people think you're being mean to them, you're probably being mean.

<comment><USER11> I don't know: in my experience pretty much everyone has a breaking point somewhere and once they reach it things can get pretty random. I've seen people I thought had it all together just completely lose the plot and disintegrate too many times to believe it's all bubbling away there, just below the surface, in all of us.

<comment><USER9> Your reasons for being an asshole don't change the end result though. It just changes the context around it.

Similarly I can understand how an aggressive dog came to be (poor training, etc.). That won't change my opinion that the dog should be put down when it mauls a kid, you know?

<comment><USER12> Perhaps it's the dog's owners who should be put down. After all, they'll just get another dog and make it as aggressive as the previous one...

Blaming an innocent for how they were cultivated is silly. Especially when those innocents can be rehabilitated.

We're getting a little off topic, but this company is just setting up another Rick to take the blame when the train goes off the tracks again.

<comment><USER9> If you read my other comments, you'll see that I agree with you completely.

That doesn't mean the dog shouldn't be put down. It just means there are also other parties at fault.

<comment><USER12> It absolutely means the dog shouldn't be put down. Dogs, and more importantly people, can be rehabilitated.

All it takes is one person in power to care enough to see to that rehabilitation to transform an aggressive "dick" back into a productive team member.

</comment></comment></comment></comment></comment></comment></comment></comment><comment> le-mark There were a lot of failures in the Rick story "on all sides" as POTUS would say. This author seems to identify with Rick and frames this type of developer as gifted, but taken advantage of. At the end of the day, we all have to manage our own careers. And in this field that especially includes "managing your manager". Whatever process you find yourself in, you have to be able to push back and say: "I'm working on X, if you want me to work on Y, what do you want first? What's the priority?"

If you find yourself in the pitiable position of fielding calls from Sales, Marketing, and Support, you need to get out of that situation by appealing to the CEO/CTO or someone. You have to have a buffer between these groups and development. If this doesn't exist or you can't get it, go elsewhere.

<comment><USER10> > _There were a lot of failures in the Rick story "on all sides" as POTUS > would say._

Nope, there weren't. That's what management is for. Everything that happened, since they didn't attempt any change, is their fault and their only.

<comment><USER13> Naw, at the very least Rick was guilty of hubris and naïveté. I came in after a Rick left once, that guys ignorance and poor decisions hobbled that company for years. Icarus is not held in high regard, by anyone.

<comment><USER12> Yes. How dare Rick be human; to be missing traits which are typically obtained by teaching, not by osmosis. The story of Icarus is, one, completely fictional, and two, a parable used for teaching such traits.

<comment><USER4> If you are in technology, either you become responsible for learning on your own or you get left behind.

I'm not just referring to learning the latest new and shiny JavaScript Framework. I learned the hard way that technical skills will only take you so far. I had to learn the soft skills.

</comment></comment></comment></comment></comment><comment><USER14> From a comment on the original post:

"Unfortunately Rick rejected months of overtures by leadership. He refused to take time off or allow any work to be delegated. He also repeatedly rejected attempts to introduce free open source frameworks to replace hard-to-maintain bespoke tools. Including the security framework as you mentioned."

Also:

"Another poster blamed management. I agree that the situation that came about was also his manager's fault. He never should have been allowed to take on so much. If it gives comfort to anyone else reading this, the manager went first because ultimately management bears responsibility, always."

<comment><USER9> This still reeks of CYA.

> "He refused to take time off or allow any work to be delegated. He also > repeatedly rejected attempts to introduce free open source frameworks to > replace hard-to-maintain bespoke tools."

Why did he have the authority in either of those last two decisions?

> "I agree that the situation that came about was also his manager's fault. "

And his manager's manager, and basically anyone who was aware of this project and the fact that it was delayed by two years.

 _Nobody_ above Rick's manager was looking into this project when it was delayed by two years? Nobody took a look at the JIRA/whatever board and saw that one person was blocking everyone despite working 100 hours a week?

<comment><USER15> Two years past a committed delivery date is a very long time in software terms and is a sign heads need to roll all over the organization.

I think an argument could be made for everyone in Rick's chain up to and potentially including the CEO should be let go.

> I'd been aware of the project for a while, because it had grown infamous in > my organization, but hadn't been assigned to it.

And especially the blog post writer who knew about the problem for a long time self admittedly and did nothing about it, only to then pat himself on the back for handling the situation poorly when it was finally assigned to him.

</comment></comment></comment><comment><USER16> A very similar scenario is described in the fictional work, "The Phoenix Project", is it not? There is a smart character who handles every escalation, but nothing is documented, he was the bottleneck, and his stress level was high.

Management had to figure out they needed to handle the escalations, prioritize, reduce the bottleneck, document the solutions, and teach others to fish.

This article seems to be addressing the same issue, albeit a bit more confrontationally. Anyone have recommendations for a non-fictional book on how managers can identify these problems and implement people-centric solutions?

<comment><USER17> Yup, very similar scenario in The Phoenix Project.

And thank you for the reminder of that. It occurred to me reading the original article and this reply to it that I may be somewhat putting myself in a Rick situation right now.

I don't have any good book recommendations, but I'd be delighted if anyone else did :)

<comment><USER11> I can sympathise. I've basically been brought in to take over from someone who was the technical bottleneck for the company I now work for so that he can get on with being CTO. For a while I was necessarily working alone, but now I've hired a team and am in the process of eliminating myself as the bottleneck: by the time I go on holiday at the end of this week I want to be off the critical path and never find myself on it again.

<comment><USER17> Are you me? :)

That's probably the solution: find at least one other person for this team. The CTO was amazingly taking care of all of the infrastructure himself, I came in to lighten his load, and I feel like we could use another person or two to bring it down to a manageable level.

</comment></comment></comment></comment><comment><USER18> I really liked both articles because they're starting to get at a fundamental issue that is at the core of a lot of the management vs engineering conflicts that tend to arise.

Personally I've been in Rick's shoes where I've been overburdened with tasks simply because product management (not necessarily direct managers) committed to accelerated timelines without consulting with the engineers. Although I brought up distributing my load to my peers, it was always deemed that there "wasn't enough time" to train them and the cycle repeated. I was always sympathetic to my direct managers because they were given an unreasonable task and had no mechanism of providing "upward" feedback or adjusting the schedule. At the end of the day I was just putting more pressure on myself. After a few years I had enough and left the company in the interest of my own well being.

At a conceptual level I think the issue is centered around making software a business. On one hand designing and implemented quality software is an iterative process and scales exponentially in terms of decision making (e.g. one week of technical debt can lead to months of problems). On the other hand businesses are deadline driven and function on a linear scale of time.

</comment><comment><USER19> _We re-released the product to this group. It consisted of 10% of Rick's original code which was pretty stable. It also had a few thousand lines of new code to replace about 150,000 lines of incomprehensible mess._ _The team had replaced five years of work in about six months. Over the next few months we expanded from pilot to full customer release._

Up next: Manager on Medium bragging that he or she would be able to type out all ~1 000 000 words in the Harry Potter series in a couple hundred hours.

<comment><USER20> I'm curious how they managed to refactor about 150,000 lines of code down to a few thousand lines.

<comment><USER21> Could be they slashed a bunch of features, but I wouldn't be surprised if they replaced a bunch of homebrewed frameworks with third party equivalents. "Line count" is such a vague measure, it's easy to get counter-intuitive results.

<comment><USER22> I used to routinely achieve 10-to-1 code refactors, without losing any functionality, and have probably done a few 20-to-1's. 50-to-1 is not really unbelievable. It's amazing the kind of pointless verbosity and over- complication some programmers are capable of.

Besides refactoring, there's also garbage cleanup. We've all seen instances of huge, 1000 line functions that do nothing because the result of their calculation was thrown away, or because it's never called in the first place.

</comment></comment></comment></comment><comment><USER23> What I find symptomatic is that everyone takes Rick being the superior genius as granted - while there is little evidence of his real superiority. In most likelihood, he was slightly more experienced then the rest of the team and knew slightly more at the beginning. The evidence of them being actually capable is there in the subsequent work. Which was better then Ricks, but note how they don't get to be praised for skill at all. Only Rick is.

The pattern I have seen multiple times in IT companies is that if you act the way Rick is described to act, you will create aura of geniality around you. If you are the slightly more experienced and a lot more confident, you rejecting other peoples ideas or criticizing their work will be unconditionally accepted as truth. And once aura is there, it is also pretty easy to frame every difference of opinion as objective truth that they are wrong.That gives others little chance in politics.

Describing experience: it does not matter that those slightly less experienced needed maybe two-three months to get up to speed, it does not matter that what they proposed was actually equally valid solution to the problem at hand. It does not matter that Rick saving day from someone else bad solution was may Rick rewriting equally valid code to another equally valid code.

What happens is that Rick acted arrogant and therefore everyone in leadership and in comments assumes he was the biggest rock star there was in the company. Other people cooperated well, therefore they are clearly less skilled than Rick was.

As for working 12 hours a day 7 days a week - it is irrational and invariably leads to inferior results. However a person who has discipline to go home, sleep, exercise, take rest, say no will not be praised as a role model, despite making better more rational decisions. Nope, the one who does irrational decisions is fallen genius hero.

</comment><comment><USER24> There are various alternative ways to interpret the story. Like, "Yay, we finally outran _one_ developer by using an entire team, and gutting the requirements." That's like moving the finish line closer without telling the forerunner.

Hey, only 5% of the users need this; let's remove it? What's 5%.

You know, that could be sometimes justified, but not always. Could we throw something out of Firefox or MS Word that only 5% of the users use?

It's not clear whether Rick himself invented all those additional requirements himself, or whether they were external.

Could it be that the man toiled earnestly to implement requirements coming at him from various people such as product managers and such? And then they crucified him for the software being too complicated due to doing things which the current political party suddenly finds unnecessary.

</comment><comment><USER25> You don't get what you deserve. You get what you get.

There is a misconception that if you do the extra work you will get compensated some way either through promotion or bonus. It's simply not true. You are paid for the position you were hired for.

Rick should have left the moment he took on more work without matching compensation. Why wouldn't the business pile more work on Rick? It's free. As soon as it costs money, all of the issues brought up in the article would be addressed. Suddenly management cares.

<comment><USER4> _There is a misconception that if you do the extra work you will get compensated some way either through promotion or bonus. It 's simply not true. You are paid for the position you were hired for._

I agree on the surface. But I would add that extra work may not get you a promotion or more compensation at the company you are at _now_ but the right kind of extra work where you are learning new skills or can say that you did a project that was important does help your resume and can make you more money somewhere else.

<comment><USER5> Plus, the people you work with and for might start their own company and offer you work, take you on as a well-paid freelancer, etc. Business is not all business.

</comment></comment></comment><comment><USER26> Documentation, while important is also a bit overrated in it's capabilities. Don't get me wrong - It would be lovely if you could simply read a bit of documentation to understand what's going on in the code. Reality is different. The details of understanding code, is in the code itself and how it connects to all the other bits of code.

The original author of the code has an understanding that far exceeds the explanatory powers of any documentation or anyone else that can come along and try to understand what's going on. By all means, attempt to document as much as you can, but don't expect it to be a silver bullet for understanding code.

<comment><USER27> I wish more people understood this.

There is no excuse to not have any documentation. One must always make an attempt to write a reasonable amount of documentation so there isn't a situation where there is no hope to understand anything except read all the source code.

But a lot of people (managerial types especially) expect docs will be "step 1 look here, step 2 look there, step 3 fix with this exact command"

Docs should explain how a system works, and perhaps some important places to look, but it's not a checklist to fix all problems. The consumer must still possess the ability, and will, to investigate and fix problems using their own critical thinking.

</comment></comment><comment><USER28> The whole situation reminded me of this sketch:

[https://www.youtube.com/watch?v=BKorP55Aqvg](https://www.youtube.com/watch?v=BKorP55Aqvg)

Given the kind of unreasonable demands, people do crack.

<comment><USER29> And here's the solution: [https://www.youtube.com/watch?v=B7MIJP90biM](https://www.youtube.com/watch?v=B7MIJP90biM)

<comment><USER30> He's missing a few dimensions.

<comment><USER31> "Dimensions" are not the part of requirements.

</comment></comment></comment></comment><comment><USER32> Right, because computer programming (unlike computer science!) does not take a genius. It is, basically, a routine work. Unfortunately, there is a tendency to say the same about fundamental science, for example here: [http://www.slate.com/articles/health_and_science/science/201...](http://www.slate.com/articles/health_and_science/science/2017/10/the_nobel_prize_does_science_a_serious_disservice.html) and here : [https://www.theguardian.com/commentisfree/2017/sep/30/we- hai...](https://www.theguardian.com/commentisfree/2017/sep/30/we-hail- individual-geniuses-success-in-science-collaboration-nobel-prize) This worries me. Without outstanding contributions from individuals, science will turn into waste of human resources. We absolutely need to protect and care about our elites !

</comment><comment><USER33> 1:1 conversations outside of normal work context can help. Dropping the work context is critical to having a human:human conversation. Most people don't have the heart to do it (for real).

If your approach always begins/ends with 'from my side' or even worse 'from our side' (team/mgmt context), you will always fail to connect with and influence someone like Rick. This sort of language will just reinforce the division between Rick and everything else.

It takes one to know one. If you know that someone like Rick is just 'so different', or if you just have that 'gut feeling', you need to find someone who can connect with Rick. An age gap (20+ yrs) helps too; reach out to the respected elders in the company.

If you can show that you care about this person, and want them to be successful and healthy, then they might start to listen to you. All you really need is their attention.

</comment><comment><USER34> Apparently they didn't fire their top talent. They fired the _worst_ talent since the team brought it together after the tyrant was vacated and the quality of the work was questionable at best when reviewed.

</comment><comment><USER35> > Instead, they played Rick like a fiddle, burned out all of his talent and > skill, and once Rick was considered damaged goods, kicked his ass to the > curb for the good of the company's productivity. How brave! How heroic!

There is always two parties involved, the player and the fiddle. The assumption that the developer was sucked empty and thrown away is the OPs alone, the article referred to does not provide details of attempts at intervention.

</comment><comment><USER36> I was a Rick once, though not by choice. The company underpaid, management received bonuses based on cutting staff, and the company wasn't a tech company. They refused to give raises or title only promotions. I tried to set up knowledge transfers, tried to spread workloads, instituted training, but it was never enough and all the work ended back with me. I eventually left and now make significantly more for less work. I've never let myself become a Rick again.

</comment><comment><USER37> Maybe the pathology is that there is no management or that it is anemic. Everyone loves the idea of self-organizing teams until something like this happens. How would Agile or Holocracy solve this?

</comment><comment><USER38> Thank you for writing this. The culture of one software developer deriding on other software developer work by badmouthing his/her work and bragging about how firing the developer solved the problem might have a place in politics but should not be celebrated/encouraged in the technical world.

</comment><comment><USER3> As someone new in this industry, I'm noticing that whoever appears more normal in meetings instantly wins any conflict, regardless of who has the most valid arguments. I find myself preemptively doing as little work as possible on days I think I'll have some sort of discussion in a meeting, since being frazzled from writing code ensures that the other party can force their demands on you without issue. It seems like people are also throwing out little jabs constantly. If you are in a relaxed state of mind, you win and they look weak. If you are worked up and respond, they win. Basically I writing code seems like a horrific waste of time on most days.

Is this normal?

</comment><comment><USER39> IMO, the most amazing quote from the original story:

      It also had a few thousand lines of new code
      to replace about 150,000 lines of incomprehensible
      mess.

No one looked at the quality of work after maybe 10,000 lines of code?

<comment><USER40> These claims make me assume the original author exaggerated everything to the point that the whole story is essentially a lie. This guy was incredibly capable but copy-pasted everywhere and wrote shitty code? This doesn't even make sense. It makes even less sense that somehow no one noticed his copy- paste coding for over two years until he was finally fired for other reasons. But then those same incompetents who didn't notice the copy-pasting or generally overengineered spagetti code suddenly came together to rebuild the whole product in a quarter of the time with less than a tenth of the code.

Yeah right.

</comment></comment><comment><USER41> Great write-up. If your software team has a single point of failure, a linchpin developer that holds everything together, then your team is defective. Regardless of the attributes of this developer, management has failed in letting it come so far.

I have quit jobs for far less severe cases of this. Feeling like you can't take time off and that the project will fail if you do not save it, is not healthy. If you find yourself in that situation, you need to seriously consider why your team is broken, and if its not your fault, quit. Find a job where you have colleagues that you can rely on to shoulder their part of the work.

</comment><comment><USER42> Could you please not spam "funny pictures" in a post like this. It makes it annoying to read.

<comment><USER40> He was mocking the original: "Look at my story! I'm going to use pop culture character names and memes and shit to identify with my audience! Whee!"

<comment><USER43> Once would have been enough. Twice to make a point. But then the point's made.

<comment><USER40> _Shrug_

Tastes vary.

</comment></comment></comment></comment><comment><USER26> Rick needed leadership coaching and he never got it. So, he never learned to be a good leader. The problem wasn't documentation. The problem was, management never taught him about the value of delegation, ROI, opportunity cost and the ability to strategically eliminate certain features for a better outcome. Maybe he didn't want to learn these things, in which case, he should have been demoted to regular developer or if he's having a bad attitude about that, then fired.

<comment><USER44> Management can't teach what they don't know ;)

</comment></comment><comment><USER45> Personally, I'm patiently waiting for the third installment: "Our incredible story"

</comment><comment><USER46> I'd really need more information about what Rick was building to make up my mind on this one. Based on what I could google about the author, he has always worked for a large research university IT department.

In this light, I've seen these back-room clerical apps, that need everyone's special requirements included, turn into boondogles of team bloat and mis- communication. If Rick thought he could ship it himself, and had a track record to make the estimate, I can't begrudge mgmt for hoping he could do it, even betting on him. As others have noted, it took a full team a year with scaled back feature set. A losing bet, that could have been played safer for sure, but maybe only wrong in project hind-sight.

From Rick's perspective, I'd speculate he was somewhat motivated by a threat of impending irrelevance, and somewhat justified in estimating the true penalty in his productivity from collaboration. Again, from snooping on the author, I think there was some Oracle, lots of Microsoft in tech stack. Knowing this type of 10x guy, his implementation style is usually somewhat deprecated from a decade of head down productivity. Also, one of the biggest problems outside "real tech stacks" is the lack of collaboration workflows and conventions. So it may indeed have been true that tripling man hours on the project could have resulted in negative productivity given the project's code base 6 months in. I still think Rick earned the right to gamble, fail, and go down with his ship. It was foolish because he would have likely only grown in esteem and compensation with some artful delegation. And doubly foolish, if his stack skills weren't highly marketable; limited upside with huge downside for him. But I find it commendable nonetheless he chose to Build when "Lead" would have been more rewarding; and ultimately if he makes the deadline, no crisis ever comes to head.

Finally, the "Rest of the Team" did what I think was the tough but right decision to move forward. No way can you "reset" the project while sustaining weekly second-guessing coming from an obsessive, knowledgeable, ego-bruised, senior team member. Ultimately, even self proclaimed logical dev's are irrational actors and as susceptible to group dynamics as anyone. We're all limited people: mgmt can't predict the future, proven-shippers sometimes come up short. I don't know if we need to read this as a call to blame.

</comment><comment><USER47> If you are a CTO or manager, please do your developers a favor by not throwing buzzwords at them in 99% of your conversations that you don't even understand. As a consequence of your vague requirements, if a developer chose to implement something that you don't quite agree with, grow a pair and suggest an alternative.

</comment><comment><USER48> The HN discussion thread for the article to which this is a response is here: [https://news.ycombinator.com/item?id=15474893](https://news.ycombinator.com/item?id=15474893)

<comment><USER49> the real MVP

</comment></comment><comment><USER50> I disagree with some of below comments and it is totally Managment fault.

I might be somewhat a little rick. But in my case it is the managment responsibility to set the expectation.

If a task takes 5 days to complete but your manager says I need build at the end of day. You can not deny it and you have no other option but to patch.

Let's assume another scenario. If your manager says he needs build at the end of day and you are spending 5 days to just write the beautiful thoughtful code than what will happen. You loose your creadibility and no one will trust you and say you are rockstar.

Then you will be fired like dumb.

<comment><USER23> It sounds like only Rick worked that much. While there is management to take part of the blame, I have seen multiple times developers working that much because they wanted to. Sometimes they thought it "must be that way", other times they wanted to pretend they are heroes to save the day and did things that could easily wait. Yet other times, they had no life out of work or messy life and this allowed them to pretend it is not the case.

</comment></comment><comment><USER51> Medium is trying to be Cracked with this article style.

<comment><USER52> Medium doesn't have editorial control over what its users post on the site.

</comment></comment><comment><USER53> "Rick" is generally actively supported by a non-technical manager who wants to keep the project from going to a more agile team ("it will take you 1000 man years to replace this and if you try we will make your attempts fail until we do it ourselves") and it locks in nice inflating budget.

</comment><comment><USER54> Based on founders'/executives blog posts, can we have a list of toxic managers/companies that people can reference whenever they are considering a job offer? This would be based on public postings about how they treated their employees.

<comment><USER36> Generally, any company that has high turnover or is replacing senior level jobs on a regular basis should be reviewed with suspicion. High turnover is an indicator of the work not being commensurate with the pay or a toxic environment. Lots of senior-level openings in a company that isn't brand new signifies a company with leadership problems or funding problems.

</comment></comment><comment><USER55> Seeing that the author of this is a security engineer, I now understand why I relate so much to this. I know this to be true - the infosec field does have it's overworked so-called rockstars.

</comment><comment><USER56> They did not fire Rick, they freed him. Ricks should not be slaved!

</comment><comment><USER57> The story given in the original Medium article reflects what is, in my opinion, the single most important thing you will ever learn as a software engineer:

Those that ask the most, give the least.

</comment><comment><USER58> likely Rick never could off load his work because of management. he may have been up against a wall of resistance where no one else did anymore than they had too. this is how you get Ricks. You have a general apathy among many of the developers which sets in because they don't see anyone held accountable so why should they exert the effort?

<comment><USER4> There are always choices — either change your environment or change your environment.

<comment><USER59> There is also another option, you genuinely like your work. For some reason, the team does not want to get involved and the management fails to notice this. Fixing the mess means either stepping up as a manager, or leaving. In both cases, you lost the work you liked. What do you do?

<comment><USER4> What is there to like about a job with bad management and bad team dynamics?

I also learned the hard way the cost of staying at a job for too long because I got comfortable - or at least was more comfortable with the devil I knew.

</comment></comment></comment></comment><comment><USER60> I briefed the original story, and one thing that stood out to me is that the author threw a 'bomb' named collaboration into the mix AFTER firing so-called Rick.

What author fails to understand, is that the problem could have been addressed by collaboration as well.

I caught a 'scrum-master' CTO wanna-be that wrote an article about (omitting my name) how he is happy I was gone because I was hard to manage. This guy showed up and hanged his scrum-master certificate on the wall and promoted a (fresh out of college) junior developer to management because he was there for a year longer than me and proceeded to enable and reward the most idiotic technical decisions I have ever seen while the rest of us was battling scalability problems.

He never talked to me; he was in the room with his new director of engineering (1 year of non-management experience, seriously) trying to come up with a strategy on how to do things and then try to run with it without getting any feedback.

Obviously, I shot them down, and it got to the point where they would come up with this stuff (no communication) and could not provide any details (why will this work? why is it better?).

I simply quit and never looked back at that point, they probably did collaborate a lot more. And by collaboration, I mean circle jerk whatever ideas sound great and force them on junior developers that do not know any better.

<comment><USER23> Except that, in this case, project continued more successfully without Rick then it did with his unofficial leadership.

<comment><USER61> I'm not entirely sure that's true. I have no evidence, I just don't think any company would have a blog post "We had staffing problems, now we're buggered". Instead it's "We had staffing problems, we fixed them, now everything is amazing".

I also don't think things would have gotten this bad if the original dev team could have picked up more of the slack, but I don't have experience in dysfunctional workplaces. Still, the "We had one guy with all the domain experience, then we fired him and all our other devs magically became amazing" thing doesn't sit right with me.

<comment><USER23> They failed at fighting Rick, they failed at politics and they quite clearly are not ready to be leaders. They did not failed at programming once the above was solved by new leader.

Yeah, because that framing is imo wrong too.

1.) In all likelihood, they Rick was not that much genius, although he might have some more more knowledge initially and probably was not bad programmer either. There is nothing to show he was genius.

Here I will make the guess: Rick belittled other people and criticized everything they did and simultaneously had more initial knowledge. That made everyone assume Rick is genius and others are low skilled. The politics follow from there. Note that other people did not slacked at work nor took three hours long lunches (I assume). Them working overtime would fix nothing.

Local praised genius belittling other employees has predictable consequences - it is that others look significantly less skilled then they are to management (yeah management is to blame too) and those people know it. It also means those people will learn to not have ideas and not have initiative, because they get insulted for those and because those invariably turn against them. As I told, it is very predictable.

2.) The other people did not turned from people who are learned to be passive to people who suddenly got agency and autonomy. Nothing in their programming skills changed, only people management of leadership of company changed.

And note how them not being arrogant still means they get comparably very little credit for technical talent or skill. (I see that as pattern in it.)

</comment></comment></comment></comment><comment><USER62> Music to my ears.</comment>


DetroitCoin: Bitcoin is theNew Vehicle Currency; make Detroit into a BitcoinHub - <AUTHOR> http://blog.inbitbox.com/post/56450714292/detroitcoin-bitcoin-is-the-new-vehicle-currency-why

<comment><AUTHOR> See the Rise of a Once Great City: Detroit's History in Maps: [http://www.wired.com/wiredscience/2013/07/mapping- detroit?mb...](http://www.wired.com/wiredscience/2013/07/mapping- detroit?mbid=social10135844)

</comment><comment><USER2> fascinating read</comment>


Militant Atheism (video, 2002) - <AUTHOR> http://www.ted.com/talks/richard_dawkins_on_militant_atheism <comment><AUTHOR> One of the bits I loved is the discussion on how the word _atheist_ doesn't make much sense (which I've always argued). Non-theist sounds like a good alternative.</comment>


Physicists Unveil World's Most Precise Clock - <AUTHOR> http://www.technologyreview.com/view/515456/physicists-unveil-worlds-most-precise-clock-and-a-twin-to-compare-it-against/ <comment><USER2> The NIST Time and Frequency Division is one of the unsung heros of physics. Their senior guy, Wineland, got the 2012 Nobel Prize.

I remember when the current Primary Standard, NIST-F1, was meeting the press in the late 90s. I was in undergrad and one of their junior guys came through interviewing for a faculty job. His lecture remains one of the most memorable hours of my life. Probably helped by the fact that I had just heard about the F1 in Scientific American a few weeks prior.

It is unclear that this particular clock will take over as the Primary Standard, whose data is compared to a competing project in France and coordinated with the astronomical measurements at the US Naval Observatory to construct the Universal Coordinated Time standard.

That is then what the USNO transmits to coordinate the GPS satellites, radio services, etc.

<http://www.nist.gov/pml/div688/>

<comment><USER3> "one of the unsung heros of physics ... got the 2012 Nobel Prize." I can't say that I would complain about being forgotten like that.

<comment><USER4> When one thinks of "power house" national labs NIST is the first thing that springs into people's mind.

</comment></comment></comment><comment><USER5> >These clocks are so sensitive that they can easily measure the gravitational redshift, in which clocks tick more slowly in more powerful gravitational fields. In other words they can sense changes in height....The new clock should be able to discern changes of around 1 cm at the Earth's surface

This seems like a pretty big deal! Perhaps not for measuring height, but measuring gravity field with such a precision can have more applications

<comment><USER6> I'm kind of curious as to how close we are to being able to use them for Gravitational-Wave astronomy giving LIGO[1] a run for its money. Anyone know if this is even possible?

[1] <http://en.wikipedia.org/wiki/LIGO>

<comment><USER7> Short answer - not anytime soon.

Longer answer: there might be a clever way to use clocks to pick off gravitational waves, particularly at low frequency, but I doubt that they'll be competitive with pulsar timing/LISA.

There are proposals to use atom interferometers for gravitational wave detection. The community is quite divided on the chances for success (I'm in the pessimistic camp at the moment). Barring any surprises, an atom interferometer is much more likely than a timing-based measurement to see any gravitational wave signal. On the LIGO front, so long as the source estimates for gravitational wave signals are correct and as long as Advanced LIGO hits its sensitivity goals, a LIGO GW detection is imminent.

There's always room for cleverness.

<comment><USER8> Could you explain why you're pessimistic on GW atom interferometers, or point me to an argument elsewhere? I'm especially interested in the AGIS proposal by the group at Stanford ( <http://arxiv.org/abs/0806.2125> ).

Also, is it obvious how one could use an ultra precise clock to see evidence for GWs? Such clock can reveal spatial gradients in the rate of ticks (and so reveal things like local mass densities), but GWs should be spatially homogeneous, no?

Thanks for any help!

<comment><USER7> There are some rebuttals by Peter Bender (his abstract for the 2013 April APS meeting may point in useful directions). For the space-based experiment, barring concerns about the technique itself, the right question may be, "Even if the atom interferometer might work, is it a better bet than the existing plans for LISA?"

I haven't studied the atom interferometer GW stuff in great detail, but the measurements look challenging from a feasibility and systematic perspective. Any one objection can be addressed, but there are a lot of them, making it challenging in the aggregate. Continued work on the ground in the atom interferometer field over longer baselines will explore both. If that work can show that it works as proposed, then pessimism will turn to optimism; experiment is the arbiter of truth.

As for the second point, regarding clocks, my initial response of "no" came from exactly your argument. I hesitated when considering a global array of clocks. For wavelengths comparable to the size of Earth and smaller, there's enough phase difference that perhaps a sufficiently precise clock, read out sufficiently fast, might pick off a signal. Additionally, if there are signals in the micro-to-nanohertz regimes, it might appear as an unexplained fit residual to an overall model of the gravitational potential at any one clock. My GR-fu is insufficient to make reliable estimates of the sizes of these effects (I bet they're small!).

<comment><USER8> Thanks so much for the thoughtful reply. I think the argument for these atom interferometers as GW detectors is that they are sensitive to a different frequency range and so would compliment rather than compete with LISA (or LIGO). (See <http://meetings.aps.org/Meeting/DAMOP12/Event/172056>) But I suppose the funding is pretty limited, so in that sense they compete. I'm actually rooting for them because the cool quantum superpositions they would need to produce (and possible sensitivity to low-mass dark matter!) rather than gravitational waves.

</comment></comment></comment></comment></comment></comment><comment><USER9> It's the combination of accuracy and precision that makes this remarkable. It's either the world's most accurate clock with a certain precision, or the world's most precise clock with a certain accuracy. I'm not sure which they actually claim.

>They say their new clocks can keep time with an unprecedented precision of one part in 10^18.

That seems to a measure of accuracy, not precision.

I can make a clock that gives the time in trillions of years since the Big Bang, and it will be perfectly accurate for the distant future as long as it always returns "0". But that's not a great precision.

I can also make a clock that gives the time in one 10^256th of a second, but it won't be accurate.

<comment><USER7> This measurement states that it's possible to build two clocks that differ by less than two parts in 10^18.

Accuracy: getting as close to the target as you can. Precision: hitting the same spot repeatedly.

The paper is correct - these measurements hit the same spot repeatedly. Accuracy in this context is a tricky thing. The SI second is defined by the Cesium standard, but the best Cesium clocks are >100 times less precise. These two clocks are hitting the same tiny spot over and over again somewhere within the fuzzy bullseye that is the Cesium target. The SI standard is not defined as well as the new generation of clocks can measure.

Once the world settles in on an optimal optical clock design (the previous leader has been an Aluminum clock, this one uses Ytterbium), the SI standard will move to the new technology.

The impressive success of these clocks as a measure of gravitational redshift is also an Achilles heel. I'm not sure that anyone really knows how to do reliable time transfer with them yet, as one's depth in Earth's gravitational _potential_ relative to another clock must be known at the centimeter scale. Another factor of 10-100 in precision will require that such metrology will improve by the same factor. It's a challenge.

<comment><USER8> I think "Achilles heel" is the wrong term. These clocks do not have an unusual sensitivity to something (e.g. vibrations) which could make them poor compared to some other hypothetical clock. Rather, _all_ clocks of this accuracy must necessarily be sensitive to these gravitational effects because the gravitational field effects the passage of time itself.

<comment><USER7> Agreed - as an experimentalist specializing in precision gravitational measurements, their lives just got worlds harder. Now they're not fighting challenges within their instruments, but they have to ensure that they _know_ each clock's depth in Earth's gravitational potential. Atomic clocks are small and elegant things with a pristine heart. They're now irreducibly sensitive to a very messy world.

Earth tides (dirt, not water) are larger than centimeters. With further improved precision, they'll be sensitive to small changes in the locations of local gravitational sources, even big ones at long range. In our gravity lab in Seattle, we see the effects of annual variation in water table. All of these things must be properly characterized in order to compare two clocks that are not co-located.

These are good problems to have, and are inherent to measuring time at this precision, but they're very daunting. Not insurmountable, but often frustrating.

</comment></comment></comment></comment><comment><USER10> _The new clock should be able to discern changes of around 1 cm at the Earth's surface_

Another reminder the amount of information hitting us every moment is absolutely astounding. That we're building devices which can collect & present that information is equally astounding.

</comment><comment><USER11> Can anyone provide more background to this point?

>And physicists rely on clocks to test the fundamental laws of the universe to ever deeper levels.

What will this instrument allow us to further discover, confirm, or understand?

This project also reminds me of the 10,000 Year Clock-- <http://longnow.org/clock/>

<comment><USER3> Presumably a more accurate clock will make it much easier to detect small relativistic effects. This could be useful for e.g. measuring gravity waves. Or it may just make it possible to do various kinds of experiments on a smaller scale. An early direct test of relativity involved putting an atomic clock on a jet to measure time dilation due to relative motion. A more precise clock might allow the same test to be done with an automobile.

In the end, the real answer to your question might well be something that we currently know nothing about. In other words: "If we already knew the answer to that question, we wouldn't need the clock."

</comment></comment><comment><USER12> awesome. when can I buy one to put in my HFT datacenter...

</comment><comment><USER13> It's about time.</comment>


Augmented Traffic Control: A tool to simulate network conditions - <AUTHOR> https://code.facebook.com/posts/1561127100804165/augmented-traffic-control-a-tool-to-simulate-network-conditions/

<comment><USER2> It's a relatively simple wrapper for tc. I think the article could have been a little forthcoming about that.</comment>


House Bill Will Ban Open Access to Scientific Publications - <AUTHOR> http://blogs.discovermagazine.com/badastronomy/2009/03/06/rep-conyers-wants-science-to-be-secret-or-you-will-pay/

<comment><USER2> These articles are interpreting the bill slightly wrong, although the end result is mostly the same. The bill bans _government-mandated_ open access, but scientists are still allowed to _voluntarily_ submit their papers to open access journals such as PLoS.

<comment><USER3> Thanks for the clarification.

Just a thought experiment: forbidding scientists to submit papers to open access journals would be a _bit_ too draconian, wouldn't it?

<comment><USER2> That sounds like it would be a first amendment problem.

<comment><USER4> It would certainly be evil, but not be unconstitutional, for the government to require government-funded researchers to publish their government-owned ideas wherever the government prefers.

If I develop cold fusion 'using university resources', then it's theirs, according to my contract.

</comment></comment></comment></comment><comment><USER5> There is a real possibility that lobbying by _scientists_ is at least behind this. I can easily imagine someone so angry that their grant forbids them from sending their paper to _Nature_ (which has prestige above any open journal) that they write to their representatives.

<comment><USER6> That is a good point. But they can still submit to the Proceedings of the National Academy, which is an equally prestigious journal.

</comment></comment><comment><USER7> I wish Americans wouldn't call a bill an act until such time as it is enacted. When I read about the Blah Blah Blah Act, it is often not clear whether it's a law or merely a proposal for a law. The British practice of always calling it the Blah Blah Blah Bill until such time as it receives royal assent is better, IMO.

</comment><comment><USER3> _"John Conyers (D-MI) apparently has a problem with this. He is pushing a bill through Congress that will literally ban the open access of these papers, forcing scientists to only publish in journals. This may not sound like a big deal, but journals are very expensive."_

Who would have foreseen that academic journals had such lobbying power? I am disgusted.

Many universities are following MIT OCW's great example and making their lectures and course materials available online for free. Only a spineless, corrupt politician would try to go the other direction.

<comment><USER6> If I remember the numbers correctly, he is getting about 4x the contributions from the academic publishing industry that non-supporters do. Anyway, all of these sums are pretty trivial.

My roomate's uncle threw around something like $40,000 in the Capitol and got a several million dollar award to do some preposterously high margin "aid work."

I expect our government to be for sale. I am pretty upset it is so cheap.

<comment><USER8> One idea I like is to pay members of congress a ton (like $3M/yr) and then execute them if they do anything wrong. Or something like that. That's like $2B/yr in salaries but would probably save $500B-$1T/yr in graft.</comment></comment></comment>


Big Patent Firm Sues Nine Tech Firms - <AUTHOR> http://online.wsj.com/article/SB10001424052748703493504576007444122372926.html

<comment><USER2> This is the biggish pile of rubbish I've seen in a while.

"Intellectual Ventures" has patents, but has never made anything tangible, or even written a progam embodying something intangible.

Every single one of the "infringements" is almost certainly due to independent invention, or perhaps "Intellectual Ventures" got a patent due to sloppy research by the Patent Office.

"Intellectual Ventures" is making a large fortune by gaming the courts, plain and simple. They need to be legally punished for this. They also need to be socially ostracized and mocked for this.</comment>


Retrospectively assessed chances of loss of the space shuttle - <AUTHOR> https://understandinguncertainty.org/files/SpiegelhalterS1.png <comment><AUTHOR> This is the direct link to the image, but I got the title " Retrospectively assessed chances of loss of the space shuttle following each launch" from the source page</comment>


Floating Point Visually Explained (2017) - <AUTHOR> http://fabiensanglard.net/floating_point_visually_explained/index.html <comment> 0-_-0 Fabien Sargland is the same guy who wrote 2 books on a deep dive into 2 game engines: Wofenstein 3D and Doom which are great reading and I really recommend them to the HN crowd (can be downloaded for free):

[https://fabiensanglard.net/gebbwolf3d/](https://fabiensanglard.net/gebbwolf3d/)

[https://fabiensanglard.net/gebbdoom/](https://fabiensanglard.net/gebbdoom/)

<comment><USER3> He also recently had a series of articles about the various ports of Out of this World/Another World to various systems which are well worth reading if you're into this sort of thing

</comment></comment><comment><USER4> For another visual explanation in words, floating point numbers (ignoring subnormal) are just a linear approximation of 2^x [1] where there is one piece for each integer (x = 4 to x = 5, etc). As an example, draw a straight line between 2^4 (16) and 2^5 (32). The floating point numbers in that range are evenly spaced on that line.

Another explanation using the window + offset terminology used in the post is that the offset is a percentage of the way through the window. So, for a window of 2^x, the difference between an offset of y and y + 1 is 2^(x-23) or 1/2^(-23) of 2^x. Put another way, floating point numbers do not have absolute error like integers (each number is within 1 of a representable value), but % error (each number is within 1/2^(-23) of a representable value). Essentially, floating point numbers use % error bars instead of absolute error bars.

Using this model you can even see how to create your own floating point numbers. Just pick a % precision you want, for single FP that is 1/2^(-23) and double FP 1/2^(-52), that defines the range of your mantissa (offset). Then pick a range of x values you want to represent, that is the range of your exponent (window).

As an aside, subnormal numbers do not respect this principle. They extend the expressible range for very small numbers by sacrificing % error for those numbers. In the very worst case of the smallest subnormal number you can get 25% error (it might actually be 50%). As might be imagined, this plays havoc on error propagation since if you ever multiply by a number that just so happens to be the smallest subnormal, all your multiplies might suddenly be off by a factor of 25% instead of the normal 100 * 2^(-23)% which is 2,000,000 times the % error which is quite a bit harder to compensate for. This is why many people consider subnormals to be a blemish.

[1] The approximation is actually offset in the x direction for the bias. If you want to be more accurate, you are actually graphing 2^(x - 127).

<comment><USER5> On the other hand, if you don't have subnormals, then you have the funny property that subtracting two inequal numbers would yield 0. This never happens with subnormals because they allow representing numbers closer to zero, below the smallest representable exponent. The numerical stability of some algorithms crucially relies on subnormals.

<comment><USER4> I do not understand your statement. I can come up with two possible interpretations, but neither seem true to me. Can you provide an example of what you mean?

I am also interested in your statement that certain algorithms depend on subnormals as defined in the floating point spec. Can you provide an example of such an algorithm? I can intuit how it might be desirable to have a single "too small/epsilon" value, but I do not see offhand how you can leverage the full range of subnormals in any reasonably generic way that is not extremely dependent on the specific problem and scale (i.e. multiply all numbers by 2^30 and increase the maximum exponent by 30, do you get the same output multiplied by 2^30), so I would like to see how it is done.

In terms of my two possible interpretations, the first is that subtracting two unequal floating point numbers yield 0. I am pretty sure this is not the case. It may yield no change, but I am pretty sure it can not yield 0. The other is that subtracting two unequal arbitrary precision numbers represented as floating point numbers yield 0. This is true, but is a known limitation of emulating arbitrary precision arithmetic using limited precision and must always be accounted for. If this is what you meant, then we can just choose numbers too small to be expressed by subnormals to cause the problem to occur again, so all it does is allow handling of a few more cases at the cost of complexity and non-uniformity. If you did not mean either of these two interpretations, can you explain what you meant, preferably with a concrete example?

<comment><USER6> If x and y are finite floats (not NaN or ±Infinity), with x != y, then x - <USER2> != 0. This is true for any pair of floats only because of denormal numbers. If there were no denormals (or denormals were flushed to zero), then if |x - y| < 2^-127 then x - y would become zero.

</comment></comment></comment></comment><comment><USER7> Wow, that's a much easier way to convert from decimal to floating point than I had ever seen. He doesn't mention why biased notation is used (i.e. why the exponent is stored as 127+E): it's used so that if you sort positive numbers as if they were integers, they'll still end up in the right order.

<comment><USER8> >"He doesn't mention why biased notation is used (i.e. why the exponent is stored as 127+E): it's used so that if you sort positive numbers as if they were integers, they'll still end up in the right order."

Could you elaborate on this? Maybe an example? This sounds interesting but I'm failing to grasp it.

<comment><USER9> [https://wiki.c2.com/?IeeeSevenFiftyFour](https://wiki.c2.com/?IeeeSevenFiftyFour):

 _"IEEE 754 […] Has the interesting and useful property that two 's complement comparisons of the underlying bit pattern of any two IEEE 754 numbers will have the same result as comparing the numbers that are represented"_

That means that, if you interpret the bits of a float/double as an int32/int64, increase that integer by one, and then interpret the bits of the result as a float/double, you get the smallest float/double that's larger than what you started with (with exceptions for NaN, infinities, +/\- zero, and, possibly, some categories I forget)

That can be useful if you want to iterate over all floats between 0.0 and 1.0, for example, but may not be that efficient on some modern hardware, where moving data from the "float side" of the CPU to the "integer side" is expensive)

<comment><USER10> This has more to do with the mantissa than the biased exponent.

<comment><USER9> No, it has to do with bothequally.

Changing a 0 bit to a 1 in an integer increases its value, and by the rule I gave, should also increase the value of the floating point number with the same bit pattern. It doesn't matter whether that flipped bit is in the mantissa or the exponent.

That requires the use of the biased number in the exponent. In particular, the "all zeroes" bit pattern for the exponent must be the representation for the lowest possible exponent, and the "all ones" one that for the highest. It cannot be the 'normal' two's complement representation of -1.

<comment><USER10> This is a different claim than the one above, which was about incrementing the least significant bit.

<comment><USER9> But it trivially follows from it. If operation _foo_ (increasing _x_ by one) makes something larger, repeated operation of _foo_ (increasing _x_ by 2^n) makes it larger, too.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> This right here is the only way I pretty much figured out just now a more precise understanding of the weird patterns going on in my head. I crave precision and this explained more than a whole year covering Basic C. Thank you so much! My head doesn't have to hurt over that anymore. I never understood floats either but this representation truly helps clear some fog!!

</comment><comment><USER12> Another visualization that blew my mind; I learnt this from a presentation that was about doing floats with FPGAs:

Think 32-bit floats as a 256-bit buffer interpreted as a fixed precision number, with the decimal point straight in the middle, but with the limitation that you can set only a continuous 24-bit window on that buffer to non-zeros.

Then, the 8 bits of the exponent determine where in the bit buffer that window points to, and the 23 (+1) bits are the contents of the window.

</comment><comment><USER10> Related, [https://float.exposed/](https://float.exposed/) is a great resource: both when trying to see how floating point is laid out, as well as when having to convert between the bit representation and the number for "actual work" ;)

<comment><USER13> That is great. Also helps remind you that for very large numbers, the precision is in the hundreds-of-thousands.

</comment></comment><comment><USER14> Didn't everyone learn scientific notation in high school? It's pretty much exactly that, and you could put the coefficient/exponent into whatever bit pattern you'd like.

<comment> GuB-42 It is scientific notation with a twist. The twist is the implicit 1. in the mantissa.

There is no easy way to make it work in decimal. So you need to learn how fractional parts work in binary, then move up to scientific notation in binary. Then you probably noticed that all numbers start with 1, so you can knock it off to save space. Oh, and add a special case for zero, because it is the only number that doesn't start with 1, and if you are feeling adventurous, there are subnormal numbers.

That's why I find the explanation in the article absolutely brilliant. By treating the exponent as a window, not only you don't need to bother with scientific notation in binary, but zero and subnormal numbers fit very nicely.

In fact, I've been working for years with floating point numbers and feel stupid for not realizing it works just as described in the article. And feeling stupid after reading something is usually a very good sign. I clicked, expected an article I could dismiss in a typical Hacker News fashion, but no, not this time.

<comment><USER15> It's an implicit 1 or 0 (because it's binary floating point). The implicit 0 is for subnormal numbers. That's the part people usually don't explain when they're first introducing it. It's literally {1,0}.xxxxxx where x is also a 1 or 0. I.e. a binary floating point number in scientific notation. I've seen a lot of explanations that kind of gloss over that part of it (not saying you don't understand it, just that even the article doesn't make that clear enough IMO).

<comment><USER16> In practice, subnormal are very rarely used. Most compiler disable subnormals when compiling with anything other than -O0. It takes over a hundred cycle to complete an operation.

Demo: #include <stdio.h>

        int
        main ()
        {

            volatile float v;
            float acc = 0;
            float den = 1.40129846432e-45;

            for (size_t i; i < (1ul<<33); i++) {
                acc += den;
            }

            v = acc;

            return 0;
        }

With -01: $ gcc float.c -o float -O1 && time ./float ./float 8.93s user 0.00s system 99% cpu 8.933 total

With -O0: $ gcc float.c -o float -O1 && time ./float ./float 20.60s user 0.00s system 99% cpu 20.610 total

<comment><USER16> I looked at the asm generate from my original example and they generate very different codes, gcc applies other optimization when compiled with -O1.

I've been fighting the compiler to generate a minimal working example of the subnormals, but didn't have any success.

Some things take need to be taken in account (from the top of my head):

\- Rounding. You don't want to get stuck in the same number. \- The FPU have some accumulator register that are larger than the floating point register. \- Using more register than the architecture has it not trivial because the register renaming and code reordering. The CPU might optimize in a way that the data never leaves those register.

Trying to make a mwe, I found this code:

        #include <stdio.h>

        int
        main ()
        {
            double x = 5e-324;
            double acc = x;

            for (size_t i; i < (1ul<<46); i++) {
                    acc += x;

            }

            printf ("%e\n", acc);

            return 0;
        }

Runs is fraction of seconds with -O0:

        gcc double.c -o double -O0

But takes forever (killed after 5 minutes) with -O1:

        gcc double.c -o double -O1

I'm using gcc (Arch Linux 9.3.0-1) 9.3.0 on i7-8700

I also manage to create a code that sometimes run in 1s, but in others would take 30s. Didn't matter if I recompiled.

Floating point is hard.

<comment><USER17> Shouldn't i be initialized?

<comment><USER16> lol, how the compiler didn't warn about uninitialized variable

<comment><USER17> Compiler warnings are not straightforward and depend on many things; compiler version, optimization settings, warning settings.

      $ gcc-9 -Wuninitialized -O0 float.c  # NO WARNINGS!!!

      $ gcc-9 -O1 float.c  # NO WARNINGS!!!

      $ gcc-9 -Wuninitialized -O1 float.c
      float.c: In function 'main':
      float.c:9:5: warning: 'i' is used uninitialized in this function [-Wuninitialized]
          9 |     for (size_t i; i < (1ul << 33); i++) {
            |     ^~~

<comment><USER16> Weirdly, those two codes behaves differently:

        $ gcc hn.c -O0 -o hn

        for (size_t i; i < (1ul<<46); i++) {
            printf ("%zd\n",i);
            acc += x;
            break;
        }

Without break:

        $ gcc hn.c -O0 -o hn

        for (size_t i; i < (1ul<<46); i++) {
            printf ("%zd\n",i);
            acc += x;
        }

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> It'd be nice to also mention about ulp [0], the unit of least precision. The floating point is an approximation as concept, and ulp is one of the properties of an implementation of floating point representation in binary form.

0: [https://stackoverflow.com/questions/43965347/ulp-unit-of- lea...](https://stackoverflow.com/questions/43965347/ulp-unit-of-least- precision)

</comment><comment><USER19> That's why when I did numerical simulation of electron Dynamics in semiconductors during my phD we never used straight SI units (m, s, kg, etc), but instead expressed all physical natural constants in nm, fs, eV, etc. That way all relevant constants had numerical values between 1 and 10 which stabilized the simulations a lot.

<comment><USER20> I had never heard of this idea before. Do you have any references to this technique? Also, depending on what equations you're using, aren't you constrained to using a consistent system of units?

<comment><USER19> Never anything official. It was just how it was done in the group and wider scientific community. Some googling pulled that up if it helps

[https://books.google.de/books?id=uzJbyD6_3DAC&pg=PA4](https://books.google.de/books?id=uzJbyD6_3DAC&pg=PA4)

And yes you have to be consistent and stay in that unit system. The other remaining two we used plain Kelvin for temperature and for the charge Coulomb was measures in electron charge. That's it.

<comment><USER21> That shouldn't matter for the factors you're describing. The number of floats between 1 and 2 is the same as the number of floats between 2^-30 and 2^-31. Until you hit denormal numbers and start overflowing or underflowing your exponent, it doesn't have any effect on precision.

If you have a process that converts floats into other formats with more restricted exponents, like human readable strings, it might matter.

</comment></comment></comment></comment><comment><USER22> Is all of that really easier to understand than exponential notation? It's a great tool to visualize floating point precision, but it's lot more circuitious to get to an understanding of what a floating point number actually means IMO

<comment><USER13> The equation fleshes out the detail that the visualization misses. I do best when I have both.

</comment></comment><comment><USER23> I always found the wikipedia examples for 16bit floating point helpful since the numbers are smaller. You can really see how the exponent and fraction affect each other in a very simple way.

[https://en.wikipedia.org/wiki/Half-precision_floating- point_...](https://en.wikipedia.org/wiki/Half-precision_floating- point_format#Half_precision_examples)

<comment><USER24> The 8-bit floating point is even easier to understand, since you can list them all in a single page, and even visualize the entire addition and multiplication tables.

<comment><USER16> Also a great format to count how many representation are wasted with redundant representation (ZeroS, NaN, +inf, -inf).

<comment><USER24> What is redundant about that? It "wastes" a completely negligible part of the representation space, and the consistency gains are enormous.

<comment><USER25> When talking about tiny 8-bit floats, it does waste a lot: if your exponent is only 3 bits, you've "wasted" 1/8 of all 256 possible values, which is a lot. With normal-sized floats, it's much less of an issue: 1/256 of the billions of possible 32-bit values, and 1/2048 of all possible 64-bit values.

(Also, the real "waste" is only on the multiple NaN values, since the zeros always "waste" only a single value for the "negative zero", and the infinities always "waste" only two values; AFAIK, both negative zero and the infinities are necessary for stability of some calculations.)

</comment></comment></comment></comment></comment><comment><USER26> Excellent article! Just one thing surprised me:

> While I was writing a book about Wolfenstein 3D[1], I wanted to vividly > demonstrate how much of a handicap it was to work without floating point

I would've expected fixed point to work fine for games, because that's a domain where you know the data, and in particular the dynamic range, in advance, so the 'automatically adjust to whatever dynamic range happens to be in the data' feature of floating point isn't needed. What am I missing? (If the answer is 'it would take too long to explain here, but he does actually explain it in the book', I'm prepared to accept that.)

</comment><comment><USER27> "(−1)S∗1.M∗2(E−127) How everybody hates floating point to be explained to them."

Now I know I'm weird, as that formula makes sense to me.

<comment><USER28> The formula makes sense, but it doesn't give you the full picture of floating points. The formula doesn't explain NaN, positive infinity, negative infinity or even the bias. I think seeing the layout of a floating point number and their constituent parts in memory is more instructive than a formula.

Floating points, like two's complement, are hardware derived/limited creations. You have to understand the underlying hardware and binary limitations to understand why they exist and why they were created in that manner. The same thing applies to ascii. Zero is 48, A is 65 and a is 97. The mapping seems arbitrary unless you see the bit pattern and you realize how clever the design is and the reason why some of the symbols got their mappings in ascii.

</comment></comment><comment><USER29> Whenever I read something about how computers _really_ work (as in not just a nice easy to comprehend programming language) I realise just how much smarter some people in the world are than me.

<comment><USER30> With every thing like that that you read, you get closer to them!

</comment></comment><comment><USER31> Here's how I like to think of it.

 _Floating point numbers are just fractions_ but with one extra condition: the denominator is a power of two.

The normal rules of fractions apply. If you want to add them, you have to make sure the denominators match, which would involve scaling the numerators too.

Just like fractions, there are multiple ways of writing the same value. 3/2 is the same as 6/4.

You can't write 1/3 exactly because, hey look at your denominator, it's 3. Which isn't a power of 2, is it? So that can't be a floating point value.

<comment><USER32> > Just like fractions, there are multiple ways of writing the same value. 3/2 > is the same as 6/4.

This is not correct. In binary you only have 2 choices {0,1} for the numerator, so 3/2 is represented 1.1 and 6/4 can only be represented as 1.1 (feel free to add the completing 0s)

<comment><USER31> The numerator is a binary integer, not a bit (and not the part of the number before the "decimal" point).

3 in binary is 11. 6 in binary is 110.

3/2 (decimal) is 11/10 (binary) and 6/4 (decimal) is 110/100 (binary).

Of course the denominators always have trailing zeros, so can be (and are) represented more compactly.

</comment></comment></comment><comment><USER33> I believe that this "window and offset" intuition, while indeed true and useful in the radix-2 ("binary") case, does not cleanly extend to the general case where no hidden bit is used even for non-"subnormal" numbers, and some numbers may thus have multiple representations. This shows up perhaps most clearly in the case of decimal floating point, but ISTR that a non-2 radix was also used in some mainframes.

<comment><USER10> Subnormal numbers are a blemish on the otherwise beautiful IEEE 754 specification :(

</comment></comment><comment><USER34> I saw a very simple visualisation of floating point by simply plotting points along the number line and zooming out. That gets the idea across very quickly!

<comment><USER35> Yes, I came across something like that in my numerical computation course. This was for me the most compelling visualization of what a floating point number was.

The floating number line is actually an (unevenly spaced in reals, uniformly spaced in binary) discrete number line that was used to approximate continuous infinite real numbers, in finite precision e.g.

Reals

0 __________________________________________________ 1

Floats

0 .. .... .. ... .. ... ... ... .. ... ... ... .. .... ... ... ... . ... .... ... .. . ... 1

<comment><USER10> A more accurate representation might be

      0.... . . . .  .  .  .  .    .    .    .    1

(Hacker News eats consecutive spaces, it seems like :/)

<comment><USER35> Correct about spacing. More accurate reproduction here:

[https://www.volkerschatz.com/science/float.html](https://www.volkerschatz.com/science/float.html)

</comment></comment></comment></comment><comment><USER36> This is a bit odd:

"Trivia: People who really wanted a hardware floating point unit in 1991 could buy one. The only people who could possibly want one back then would have been scientists (as per Intel understanding of the market). They were marketed as "Math CoProcessor". "

The 486DX (1989) was already common in 91/92 and came with a floating point unit. I had a 50mhz 486DX, and I was not by any means wealthy. FP unit was certainly used by lots of software, especially things like Excel, but C compilers certainly produced code for it if you had one.

Likewise, the 68040 (1990) had onboard FP. Macintosh Quadra, Amiga 4000, and various NeXT models had it.

Yes if you bought a 386 you often had to get a floating point co-processor as upgrade, but it wasn't _that_ uncommon. Same on the 68k series; I knew people with Atari MegaSTes (68000) that bought an FP co-processor. They weren't astronomers :-)

This feels like recent history, am I really that old?

</comment><comment><USER37> I remember wanting a math co-processor so I could use autocad at home as a kid.

<comment><USER38> And now you could probably buy an expensive Tesla V workstation dedicated to that but you don't have time anymore. Wait. No. That is me :P !

</comment></comment><comment><USER39> Interesting, because I think about it the other way: the offset tells you between which power of two you're in:

* [2^-127, 2^-126] * ... * [1, 2] * [2, 2^2] * [2^2, 2^3] * ... * [2^128, 2^129]

and the window tells you where you are in this "window". You have 8 bits to figure out where you are in there, so it's obvious that you have much more precision if you are in the window [1, 2] than in the window [2^128, 2^129]

</comment><comment><USER40> [https://opencores.org/projects/fpuvhdl](https://opencores.org/projects/fpuvhdl)

</comment><comment><USER41> I wonder why the significand is represented as a > 1 number. It complicates representing zero (making it a special case not covered by the article of defining exponent=0, mantissa=0 to mean zero). Is it for the purpose of simplifying arithmetic operations or is it to minimize the number of redundant representations of zero?

<comment><USER42> The leading 1. prefix can be omitted from the binary representation thus saving a bit in the process.

<comment><USER41> That doesn't answer my question, though. I'm asking why the significand is in the range 1-2 instead of 0-1.

</comment></comment></comment><comment><USER43> A thread from 2019: [https://news.ycombinator.com/item?id=19084773](https://news.ycombinator.com/item?id=19084773)

Discussed at the time: [https://news.ycombinator.com/item?id=15359574](https://news.ycombinator.com/item?id=15359574)

(Reposts are ok after a year or so.)

</comment><comment><USER44> I remember wondering at first how you know this won't have multiple representations and cover every number - it's because the mantissa can't reach 2, and if it was 2 it would be the same as adding to the exponent, so you get the full range between any two exponents.

<comment><USER16> Ackchyually...

The IEEE-754 has a lot of redundant representation. Not where you would expect though.

Caveat: Those features are invaluable for some niche applications, but not for the average joe.

To start. Every IEEE-754 float has two zero representation: one for positive zero and another negative negative zero (sic).

The special numbers are another source of redundancy. The the double format, have about 9,007,199,254,740,992 different combination to encode three different states that a production ready software shouldn't reach: NaN, +inf and -inf.

Other than the redundancy, the double have many rarely used combination. For instance, the subnormals representation. Unless you are compiling your program with -O0 or with some exotic compiler, they are disabled by default. One subnormal operation can take over a hundread of cycles to complete. Therefore, more 9,007,199,254,740,992 wasted combination.

If that wasn't bad enough, since the magnitude of the numbers follows a normal distribution (someone whose name I forgot's law), the most significant bits of the exponent field are very rarely used. The IEEE-754 encoding is suboptimal.

The posit floating point address all those issues. It uses an tapered encoding for the exponent field.

<comment><USER45> I'm mixed on Gustafson's posit stuff. For me, the only thing I'd change for fp would be:

1\. -0 now encodes NAN.

2\. +inf/-inf are all Fs with sign: 0x7FFFFFFF, 0xFFFFFFFF.

3\. 0 is the only denorm.

Which does four _good_ things:

1\. Gets rid of the utter insanity which is -0.

2\. Gets rid of all the redundant NANs.

3\. Makes INF "look like" INF.

4\. Gets rid of "hard" mixed denorm/norm math.

And one seriously bad thing:

1\. Lose a bunch of underflow values in the denorm range.

However, as to the latter: who the fuck cares! Getting down to that range using anything other than divide-by-two completely trashes the error rate _anyways_ , so why bother?

The rest of Gustafson's stuff always sounds like crazy-people talk, to me.

<comment><USER16> He also propose the use of an opaque register to accumulate (quire), in contrast to the transparent float register (its a mess, each compiler does what it think is best).

When working with numbers that exceed the posit representation you use the quire to accumulate. At the end of the computation you convert again to posit to store in memory, or store the quire in memory.

In C, it would look like something like:

        posit32_r a, b;
        quire_t q;

        q = a; // load posit into quire

        q = q + b; // accumulate in quire

        a = q; // load quire into posit

> The rest of Gustafson's stuff always sounds like crazy-people talk, to me.

I've read all his papers on posit and agree. But I do believe the idea of encoding exponent with golomb-rice is actually very good and suit most users. The normalization hardware (used in the subtraction operation) can be easily repurposed to decode the exponent and shift the exponent.

But the quire logic (fixed point arithmetic) might use more area than a larger float-point. But maybe in power usage it pays of.

<comment><USER45> I come from GPU-land, and a quire always brings a chuckle from the fp HW folk. They like the rest of Gustafson's stuff, though.

<comment><USER16> Yeah. Gustafons is like, memory is cheap, just use a few hundreds of kb to store the quire. To be fair, he is not HW guy.

</comment></comment></comment></comment></comment></comment><comment><USER46> This guy's Quake 1/2/3 source code deep dives are well worth checking out as well.

</comment><comment><USER47> Awesome. Maybe now I can finally understand the fast inverse square root hack.

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

</comment><comment><USER48> This is beautifully written. Bravo to the author.</comment>


Ask HN: How do I get by on less sleep? - <AUTHOR>

I am a college student and after I did poorly last semester, I'm studying way more hours. Let's say 5 hours a day. I am often falling asleep as soon as I put down my books these days. On top of that, I'm working averaged out, about 5 hours a day. Add to that the time I spend eating, being social, in classes, and an hour here and there doing nothing and the day is long gone, It's 4 am and I get back and crash. I really milk my productive time but increasingly, I'm unable to be productive or study effectively because I'm tired.
I tried sleeping more but as a consequence, I felt no more awake (sometimes even more tired) and I got way less done ie: wasting several hours between sleep and productivity.
I have been trying to exercise but I do very little of that. Maybe twenty minute walks between campus and my apartment a couple times a week, but I could never find the motivation to go the gym.
Should I bike for 30 minutes every day? What that help? <comment><USER2> _I'm unable to be productive or study effectively because I'm tired._

If you're too tired to be productive, then there is only one productive thing you can do: Sleep.

</comment><comment><USER3> First thing first, you need your sleep. If you don't sleep the brain stops working properly and everything becomes increasingly difficult. Short term (cramming before an exam) -- OK. Long term, don't do it, it's not worth it.

Better to look at productivity strategies which someone else will be able to help you with. You're right about the exercise as well, getting oxygen into the brain, and generally being fit, will help the brain work.

But please, sleep. If needs be do it in 2 or 3 shifts over a day/night, but one way or another you should have at least 7 hours in every 24.

</comment><comment><USER4> Before exercise comes diet.

As a rule of thumb try not to eat anything that you couldn't get 200 years ago.

Cut out ALL sugar. (not _literally,_ see comment thread) Make sure you get fiber. Make sure you get water. Dehydration manifests in a lot of ways.

Soda? Stop.

Coffee? Stop. No coffee? Consider starting. Be moderate.

Right after diet, of course, comes exercise. It can't hurt to bike 30 minutes a day.

How do you feel when you wake up on a saturday? When do you wake up? How consistent is your bed-time?

Quality of sleep is important. Are there too many lights on in the room? Too loud? Too cold? What kind of clothes do you wear to bed?

Also, while you're at it, it can't hurt to install f.lux:

<http://www.stereopsis.com/flux/>

<comment><USER5> > Cut out ALL sugar.

Considering sugar is fruits, vegetables and milk, this sounds like a bad call.

<comment><USER6> I think he means sucrose (table sugar), not starch (glucose) or lactose. Sucrose, more specifically fructose (half of sucrose), has been targeted as the bad guy. See Robert Lustig's talk, among others. Obviously cutting out ALL sugars would be a bad call.

</comment></comment></comment><comment><USER7> If you are trying to sleep more by sleeping in, that will happen. You need to wake up at the same time every morning and practice good sleep hygiene. If your body is used to waking up at 8AM most days and you try to sleep until 10AM, it will resist. Given that you say you go to bed at 4AM I imagine your sleep schedule is all over the place - that just won't work.

30 minutes of cardio every other day has done wonders for my energy levels, but I sleep 7-8 hours a night. People who exercise often sleep a little bit longer.

</comment><comment><USER8> Get more of the right kinds of sleep by monitoring yourself.

A $1 way is the Sleep Cycle app for the iPhone: [http://lifehacker.com/5441045/sleep-cycle-analyzes-your- slee...](http://lifehacker.com/5441045/sleep-cycle-analyzes-your-sleep- patterns-for-a-better-wake+up)

The best way IMHO is the Zeo: <http://myzeo.com>

The Zeo can save you time everyday and help you wake up feeling better. Disclosure: I went to school with some of the founders.

</comment><comment><USER9> A twenty minute walk is definitely not enough to be called exercise. I do a twenty minute walk just to get to the gym.

</comment><comment><USER10> Nutrition, exercise, get no less than 7-8 hours sleep a day. Don't cut corners.</comment>