quantumhobbit

Who else thinks he's hype driving the price up to dump the shares he already owns at a profit? He clearly has no reason to fear the SEC...

I’ve always wanted to try this out in practice. It seems like it would be a great way to find gaps in the specification.

There was some research in the early 90’s over multiple implementations as a way to avoid bugs. I still feel like it was dismissed prematurely or could be revisited.

Don’t forget the drugs and money laundering.

My work would insist on calling the incident response or monitoring room a "war room". And I would quote this every time it was mentioned. It gets old, but I literally can not stop myself from repeating the quote when i hear the phrase "war room".

I absolutely have to plug the author’s latest book, Wanderers. It was pretty amazing.

How about multiple day battery life?

You probably don’t even need that much more battery, just a smaller screen and slower cpu/gpu.

My high school cross country running coach used to navigate by Waffle Houses. As in “4 more Waffle Houses til our exit”

14 cents per ride is nothing! Maybe 1% of the cost of a ride.

Maybe they could save a bunch by colo or something else. But would 14 cents per ride really matter at all for their competitiveness. I’m not going to notice a 14 cent difference even if I do bother to price compare Uber with Lyft.

This is a VC fueled market. It isn’t really about small margins of this size.

If the company can’t figure out how to add a date to the subject line, they won’t be able to figure this out either.

It’s gmails bug, but I’m amazed they couldn’t figure out hiw to implement the fix. Amazed but not too surprised given how not nimble big companies are.

There was a boy called Eustace Clarence Scrubb, and he almost deserved it.

Many here are commenting that you should pay more and that is true. But how about not wasting the talent you already have?

I’ve had several jobs from startups to big companies and I have never been utilized at anything close to 100% of my potential.

Try getting rid of pointless meetings, distracting open offices, insane IT policies, and needlessly overcomplicated architectures. You may not even need to hire any more enigineers if the ones you have are more productive.

Overcast seems to bug out on me everytime I try to play episodes in the order they were released instead of most recent first.

It also never removes played episodes no matter what my settings.

Seriously these should be simple things.

We used to macgyver particians out of white boards and project posters.

Super common. More common than the opposite.

In fact a version of the above story has happened in the last two companies I worked for.

Until they get bored writing grant proposals and lose all their funding.

How is the battery life on the oryx?

Not really relevant, but if you have a recurrent c-diff infection, eating a warm turd is pretty close to the empirically proven treatment.

https://en.wikipedia.org/wiki/Fecal_microbiota_transplant

The making everyone else come in is the worst.

A senior to me dev started working nights. I didn't even know he was doing it but I got in trouble for not being there when he was working. Because I "wasn't available when he needed me".

Bruce Webster calls this the Thermocline of Truth. Which I think is a great metaphor.

http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-t...

Does this factor in the cost of lost productivity from having an awesome gaming pc always available?

At an old job I managed to snag a 30" monitor from a colleague who was moving to a different job. He managed to get it in the brief window that it was offered instead of 26" ones. When I announced that I was moving on, the vultures started circling over who would get the monitor.

The inventory sheet will never be reconciled over that monitor, unless it breaks.

Not my direct manager but the tech lead.

This was a new team with an early standup which never happened on time because we would always roll in late. The scrum master had the 'great idea' to start a dollar jar. Whoever was late to standup had to put a dollar into the jar. None of us objected because other than the scrum master, tech lead, and manager we were all new to the company and didn't want to rock the boat.

This turned out to a huge problem for one of the engineers. She had to drop her kids off at a daycare that didn't open early enough, so she was late ever day. We mostly fell into line but she didn't have a choice. It wasn't the money, but the public shaming of having to go up and put the dollar in the jar. After a few weeks she was really stressing out about it because she was new no the job and wanted to make a good impression.

Well the tech lead saw this and sauntered into the office at 11 the next day. He flourished a twenty dollar bill and then announced so that the whole office could hear that he was pre-paying for the next month. He could do this because he was one of the most talented and senior engineers in the whole company. And unlike many talented people who toil in obscurity, upper management knew he was talented. The project wouldn't happen without him, or at least thats how management saw it. He was untouchable.

The dollar jar disappeared the next day. The woman who was afraid of losing her new job over a stupid tip jar would up staying and becoming one of the better and most reliable engineers at that company. Even if it took them a few more years to realize it.

There are just too many unknowns to do estimates well in software. And getting things wrong in estimates isn't a matter of being off by a couple percentage points but being off in by orders of magnitude.

It isn't unusual for what appears to be a simple unit of work that seems like it should take a few hours to explode into days or weeks of work. And it does so in a way that is completely opaque to stakeholders.

Partly this is because of how we build software as layers of abstraction on top of other layers of abstraction. When you are at the top layer things are relatively quick and easy to estimate, but once you have to work at a lower level than normal all bets are off. And it is really hard to know beforehand if you will need to dig into the lower levels.

For example at my job I am updating an app that queries an api to filter its requests by some parameter. When the api supports the desired filter that is great. When the api doesn't, I have to dig into unfamiliar code for the api to support it. But turns out the api is just forwarding its request to another api, so I have to dig into yet another api to build the filter. And so on. The rabbit hole can get deep. And of course there isn't any documentation to help me know about this beforehand.

The article is right that the key is frequent updates and communication as soon as "blockers" like this are discovered. But it can be very difficult to communicate this to stakeholders who are uninterested in the technical details and are inflexible in scope. Trust is key, so that they believe you when you say that this task which normally takes an hour or so will now take several days.

Likely changes to the coast itself. For example Louisiana and the gulf coast are going down faster, because of coastal erosion.

I would guess that the parts of Alaska that are seeing the sea level fall are due to the land rising from tectonic activity.

Things like changes in water temp and currents can also play a role.

Right. Code Review should be about catching mistakes. The high level design is already known, and the low level details are checked by a linter. Code Review just makes sure that you didn't accidentally introduce a bug and that the code has appropriate tests.

One of the best managers I ever worked for was a “people manager”. He knew his limitations and worked within them. He was reliant on the tech lead for technical knowledge but between the two of them made a pretty good team.

Some of the worst managers I’ve worked for have been technical people who don’t really want to manage but git Peter Pricipled into management.

I just left a job with a truly toxic code review culture.

- managers would swoop in and leave incorrect criticisms. Asserting plainly false things and in one case reviewing python code as though it was JavaScript.

- devs would make conflicting requirements for improvement. Dev A demands change A. Dev B wants change B. A and B are incompatible and neither dev will back down. Management of course refused to help settle the argument.

- change requests completely unrelated to the PR being reviewed would get crammed into the PR. So every small code change could balloon into weeks on refactoring work.

- Often times code review comments were made without ever reading the code being reviewed. Such as a comment of “Why aren’t you using library X?” sandwiched in between invocations of library X.

The culture was clearly rewarding people for shitting on others work instead of doing any work themselves. Getting even the simplest code changes past required endless meetings explaining the most basic facts about computers.

So glad to be gone from there.

This is stupid. If you are a react shop and you would have been ok to see some Angular on the CV, then you are clearly expecting the new hire to do some learning on the job. Why not try to figure out if this candidate is up to the task of learning your framework?

Also I tend not to put technologies on my CV unless I have done something more substantial than online classes and tutorials. I don’t want to have to answer an interview question about “what’s your experience with Foo?” with “oh just some tutorials...” . That would cast doubt on the rest of my experience. Ask the candidate if they have experience in any frameworks and they might surprise you and say that they have been learning one in their spare time.

Chaotic rotation occurs primarily in bodies that are not spherical. These tend to be smaller, because gravity forces larger bodies into spheres, and would have a thinner atmosphere if any due to the small gravity.

Not saying life is impossible on such a moon, but it would be even weirder than just strange day night suggests.

Evertime I hear someone defend something as a best practice without any other justification, I mentally switch “best practice” with “cargo culting” and lose no information.

Sometimes the best practice in question does have value and can be articulated. But in those cases the articulated reason makes a better argument and you don’t hear the phrase “best practice” quite as often. When it is just cargo culting, the only defense is to repeat “best practice” over and over again.