technofire's comments

He has two math degrees from decent (R1, AAU) schools, so I wouldn't say it's a huge leap; he probably has better training for modern AI than most people working in the area with CS degrees.

> All of this inevitably leads to a bunch of pissed off devs. The ones that are happy to eat it become the golden boys and get promotions.

The question asks about behavior that management repeatedly makes. If management repeatedly makes these mistakes, then the mistakes should become expectations, so one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish.

Of course, by "accept them" I don't mean one should never try to influence or change the situation, but reacting emotionally rather than rationally is silly. Even if there are no upward-feedback or 360 review procedures in place at the workplace, one can articulate these concerns more diplomatically (less offensively) and send out an email requesting that they be considered. One can even illustrate and trace through how such mistakes have impacted recent projects.

It seems to me that the ones "happy to eat it" simply understand that others have limitations and make mistakes and will try to make the best of the situation. It sounds to me like such people indeed deserve the promotions more than people who bring anger to bear on their work.

The funding implies a requirement that you will work on research, which for most people would preclude working a full-time software engineering job. Assuming a full-time job would bring in more income than the tuition plus stipend, when we take opportunity cost into account, pursuing the OMSCS while working full time still is financially less expensive.

One reason CEOs are paid so much is to offset the risk involved in accepting the position. If a CEO performs poorly, that's often the end of their career, so the high compensation makes that gamble more acceptable.

"Pittsburgh has some important advantages over most would-be startup hubs." --Paul Graham, 2016[1]

[1] http://www.paulgraham.com/pgh.html

> as well as the characters

While I cannot recommend any books on physics itself, I can recommend a couple light reads on Richard Feynman, the Nobel prize-winning physicist (links below). Each is structured as a series of short autobiographical stories so they're very easy reads that shed light on some of Feynman's life, both within and without academia.

[1] Surely You're Joking, Mr. Feynman! (Adventures of a Curious Character)

http://amzn.to/2gTVXa5

[2] "What Do You Care What Other People Think?": Further Adventures of a Curious Character

http://amzn.to/2gTWfOd

Very cool! When you say you "collect the data from Amazon," are you scraping this or using an API? If the latter, which API and where can I go to read about it? I also would love to be able to query this kind of information from Amazon.

I have 2 recommendations:

1. "Thinking Strategically," written by a professor at the Yale School of Management and an economics professor at Princeton.[1]

This one is basically a primer on game theory, which I think would be useful for you particularly if you are facing off someone at work. It gets you thinking about incentives of each party and figuring out the different ways situations could play out.

2. "The First 90 Days," published by Harvard Business Review Press.[2]

Obviously, it's targeted at those transitioning into a new leadership position, but in my opinion the strategies can apply even to those who are in incumbent positions as it's never too late to turn the page and start taking a fresh approach or step up one's level of effort at work.

It includes an actionable plan for feeling out the pain points of others you need to impress and tackling their problems in a visible manner. This one is less about politics per se but more about being a very effective leader in a highly visible manner, which can help one to move up the ladder.

[1] http://amzn.to/2vwXwhH

[2] http://amzn.to/2uLYXLI

Perhaps a better question is "Why is anything normally distributed?" It appears originally to have been a simplification to make the math more convenient:

As Rand Wilcox reports, "Why did Gauss assume that a plot of many observations would be symmetric around some point? Again, the answer does not stem from any empirical argument, but rather a convenient assumption that was in vogue at the time. This assumption can be traced back to the first half of the 18th century and is due to Thomas Simpson. Circa 1755, Thomas Bayes argued that there is no particular reason for assuming symmetry, Simpson recognized and acknowledged the merit of Bayes's argument, but it was unclear how to make any mathematical progress if asymmetry is allowed." (Wilcox, p. 4)

Wilcox, R. (2010). Fundamentals of modern statistical methods: Substantially improving power and accuracy (2nd ed.). New York, New York: Springer.[1]

[1] http://amzn.to/2tkMRoI

O'Reilly just published an updated edition of their bestseller on Bitcoin technology, "Mastering Bitcoin," earlier this month.[1]

For a more general/conceptual understanding of blockchain technology and its applications, including non-cryptocurrency applications, "Blockchain Revolution" is a good read.[2]

[1] Mastering Bitcoin http://amzn.to/2uewdK9

[2] Blockchain Revolution http://amzn.to/2vniXSf

I agree with several other users on this thread about maintaining existing code. If you aren't already working in a position in which you have to modify code written by others, try to start fixing bugs or writing features for an open source project. In either case you should immediately see how frustrating it is to try to figure out why things in the code base are the way they are, and I think the best solution is not documentation but clear, clean code that self-documents, not with comments but with small focused recipe-like functions. Bob Martin's book Clean Code[1] is a quick read that makes clear how this can be done effectively. Martin Fowler's book[2] is another obviously good illustration.

The second thing that has really influenced my coding style for the better (making it clearer and easier to understand) is writing a medium-sized program using a strictly functional language like Erlang. This will force you to use global state less, to write functions in such a manner that the function itself includes all the information required to understand it, simply because global state cannot be used and everything on which the function operates must be passed into it explicitly via its parameters.

[1] Clean Code (Robert Martin) http://amzn.to/2uewcpB

[2] Refactoring (Martin Fowler) http://amzn.to/2vnD7vx

> if we're going to throw in hyperbole, it should at least be somewhat accurate

Exaggeration is an essential part of the definition of hyperbole. Merriam-Webster literally gives the definition of the word simply as "extravagant exaggeration."[1]

[1] https://www.merriam-webster.com/dictionary/hyperbole

If a bunch of people move to the middle of nowhere, they will need goods and services, and thus jobs will be created as enterprising people move to provide them.

I think what he's getting at is that whatever program is reading the text must be prepared to read UTF-8 and not just ASCII. Sure, the underlying data is the same, but the data type is not the same; analogously, a byte with the decimal value of 65 might be the number 65 if cast as an integer, but might be the character 'A' if cast as a char.

Second-guessing yourself is a good sign. As Michael Atiyah said, "Only the mediocre are supremely confident of their ability. The better you are, the higher the standards you set for yourself."

No, precisely the opposite should be said of engineers. Engineering is about reusing well-known techniques to achieve repeatable, predictable results whose timelines can be estimated. Engineering is not art. When civil engineers build new buildings or bridges (and I'm talking about your common building or bridge, not some iconic project), do they try to innovate and undertake to do things in some new-fangled way every time? No, because this would be extremely costly and dangerous and would render useless much of the past work that's been done testing materials and loads and so forth. When a method is known of constructing a bridge or an overpass that is both safe and economical, a good engineer should just keep doing that, with perhaps some adaption as appropriate on a case-by-case basis.

If software developers would stick with tried-and-true tools instead of inventing new frameworks to solve the same old problems and immediately obsoleting the "old" way of doing things each time, we'd have much less legacy code and likely would be much better at estimating software development tasks, and wouldn't have to solve the same problems over and over again.

FYI, when I attempt to view your resume I encounter:

"You and this LinkedIn user don't know anyone in common ... You can only view the profiles of users within your network. However, as you add connections, you may discover people you know in common."

You might want to adjust the public profile privacy controls on LinkedIn so that the public can view this.

Synopsis:

"Flush with cash after raising more than $5 billion from investors, Uber offered some scientists bonuses of hundreds of thousands of dollars and a doubling of salaries ... In all, Uber took six principal investigators and 34 engineers. The talent included NREC’s director, Tony Stentz, and most of the key program directors."

> This is an executive action.

Not quite; some restrictions have been lifted but this is not yet a done deal:

"Although the decades-old American embargo on Cuba will remain in place for now, the administration signaled that it would welcome a move by Congress to ease or lift it should lawmakers choose to."[1]

[1] http://www.nytimes.com/2014/12/18/world/americas/us-cuba-rel...

It seems you've overlooked "Penthouse" near the bottom of the list in 1996.