spotman

This feels akin to saying a subway or hospital or giant computing entity can easily upgrade its mission critical systems. Does not feel realistic. These things tend to move slowly once stable. A client is usually easier to upgrade than a server, if all the brains live on the server and the system achieves stability it would rarely be touched; now it's responsible for life and death.

Furthermore it seems that the paradigm of automatically updating each car independently at night ( like modern computers/etc ) would be less prone to major failure. Updates can be rolled out automatically when the vehicle is not use and can be done in stages, not all in one big shot.

Lastly what about bugs and fault. With the cars and systems still being private we get to reuse and evolve from the legal structure we have now, especially including 'fault'. In this utopia idea proposed we have a big official system keeping us all safe. Would imagine the first big failure to be expensive with a lot of finger pointing and a broke city that won't want to pay for all the injuries and damages, or would need a bailout to do so.

This idea is not fault tolerant or distributed enough to to live with our current amount of chaos. Getting to utopia is harder than it sounds.

I don't want to live in a vehicular system with a single point of failure even if that single point of failure is an organization such as a government and this is seen as a utility.

Possibly this day will come, but the idea is way ahead of its time. Good luck!

would you rather have a team of engineers worrying about performance or building features rapidly?

there is many shops that would rather have some percentage of less performance if that means software is being built faster and usually with less bugs. these places may need some extra servers even but the cost of a server or two is nothing compared to a developers time.

this doesn't scale of that cost ends up being millions of dollars to run the slower code of course. but by that time you will have written your own in house framework likely anyways.

build something you believe in, that solves a real problem, and gain real traction.

if people see the value in what your doing and plan on using it, chances are a big company would too.

depends on your project and its complexity.

perhaps one way to improve the approach is instead of thinking about your design and if it's perfect, encourage thought along the lines of "how do we build this so we can change how it works later?"

things always change. there is no perfect spec or style on day 1. the best code is always written during refactoring, so design to make that part easy and while your idea is new and not launched optimize to get it launched.

avoid negativity and negative thinking. be pragmatic and realistic. ride the waves of passion and encourage passionate work, but also encourage balance and health and try to be a leader in both regards, keeping your own work velocity up, but not getting burnt out it not taking care of yourself.

learn your team and respect them. work at earning their respect. don't expect more work out of them than you put in. if you assign a dev 3 issues assign yourself 4. if that's not possible go out of your way to be transparent. developers are motivated by progress and want to see deliverables; so transparency about where you spend your time can help, especially at first.

create an environment where it's ok to fail. both with software architecture and human challenges. avoid creating an environment where people can't communicate or ask for help.

don't be passive aggressive, always be direct. be light hearted and have a soul, but don't get stuck being too nice and let that prevent you from being firm as needed. try to balance this out with letting people occasionally make their own mistakes and learning from them if it's in an area of the project that can afford to invest time in this learning. sometimes you can to force a good decision by being firm, but if you can let it evolve organically the person will feel they achieved more.

try to do your best work and encourage that in others, but always calculate some buffer for things not always running at full tilt every day.

good luck!

Yes. Pinterest is big but it's not Amazon, Google or Facebook big. With things like reserved instance pricing, and not having to spend as much money on a physical ops team that can manage real hardware, it leaves room to optimize software and cloud architecture.

without knowing the specifics of their workload I would bet that it's probably a draw at their scale. they may be big enough to start considering this sort of transition... but, it also takes a significant amount of time, energy, people and energy to make that transition, so they probably won't do it until it's a no brainer.

Curious if the numbers in the article are their entire db workload, 20-30k qps. If so they have a while to go before they are ready to graduate from the cloud in my opinion. (having no idea of the real meaty specifics, but imagining as it is similar in function to many that I have worked on).

maybe productivity is irrelevant, and it's simply a case of being overwhelmed because your learning all of these at once?

productivity is never as good when your learning something vs when you have mastered it.

imagine your working on a team, and most of the fellow devs are comfortable with many technologies. now compare this to a team where everyone only has one role or technology. in this scenario ( certainly exceptions to this but ) in my experience the team where people can work on anything is leagues more productive.

I think that a large portion of this is attitude and not skill. to be full stack you often have to be ok with diving into a task that is not your specialty. not everyone is ok with that.

being a specialist is hard these days. I have hired specialists before but they have to add something very special and unique to the rest of the team that very few people can do.

I wish you weren't right, but I agree. smoke, mirrors, and consistency. sigh.

The browser tabs have an upper limit sure, because on the client/browser side, it just might be unfeasible to open more than 100 tabs realistically.

But, I can assure you, you could open 1000 tabs, and dynamo will be fine, and not lose your data.

You should really read the article I linked, especially the part about vector clocks, it discusses a common approach for dealing with duplicate data, conflicts, and resolution, at scale.

There is no SQL triggers in the article you post here. Confused at what your trying to say here. Maybe you can elaborate?

I agree with you in spirit, but it's simply inaccurate to suggest that a shopping cart does not deal with mission critical data.

the fact is, Amazon does use Dynamo for a mission critical financial purpose. If Dynamo lost data Amazon would not use it for arguably one of the key pieces of their success.

the article I linked covers how they do this, and how it stays accurate, scalable, and robust.

anyways cheers, I hope we have not hijacked this thread about MySQL bugs too much.

I agree with a lot of the sentiments in this post, but I wouldn't go so far as to say beginners should not learn node at all. (i.e. - stop teaching it to beginners)

It boils down to using the right tool for the job. As the author mentions, some people do get it right, but it leaves you a lot of rope to hang yourself.

There is people who feel teaching rails or django to beginners is also doing them a disservice too, because at times it can mask how SQL or other things work, and can encourage developers to not learn how things work at a lower level.

Developers should learn SQL before noSQL, but I don't think that will make or break a career, nor will learning node first or rails or php or java.

One key to being a diverse developer, is not being religious about any one technology, but try as many out as you can reasonably, and learn from all of them.

The author definitely nails this point, that people are often "unwavering" in how they support node (or insert another technology in that sentence).

TL;DR - use the right tool for the job. Sometimes it's node. Sometimes it's not. At least that is my take on the article. Cheers.

Yes, agreed, if we are talking about straight concurrency only.

Other things like replication, are also not there, so it's not what I would choose for a website database, but if you can serve all your reads from one server, and don't care about high availability, then go for it.

Nicely put. 100% agreed.

Agreed overall, see my comment above which addresses this. These types of systems typically will never see as many transactions/sec as their “likes” counterparts, for obvious reasons.

Having said that, I have worked on some credit card infrastructure that does get up there, and it too, does not have FKs. Having or not having FKs does not magically mean your data will be accurate or in-accurate. ACID, as well as traditional database transactions, still apply, and keep your data integrity high. In conjunction with well designed application logic, and proper planning, FKs are not needed to maintain accurate data whatsoever.

Also, there is commerce related things (Amazon) that work on truly eventually consistent data stores, like DynamoDB. Don’t see amazon getting laughed at much. (they use it for their shopping cart, source: http://www.allthingsdistributed.com/2007/10/amazons_dynamo.h... , this paper is also a great read fwiw)

Anyways, I think we are getting a bit into the weeds here, as the OPs link is about a mysql bug. Cheers.

Let me explain better. As eventually consistent is probably the wrong term for what I mean.

In things like a large social media app where the reality is no FKs, and 100k queries-per-second, for instance, you would write into your application logic how to deal with child rows and parent rows, and not rely on FKs to raise an exception, or perform cascading deletes and things.

So if ( when ) there is either a bug, hiccup, or a variety of other reasons that can as you mention make things question correctness (or specifically: referential integrity, if we are going to nitpick), these are usually cleaned up out of band.

So you may have a table you have to slowly iterate through later and remove rows in which their parent rows no longer exist anymore, as an example.

In something like the friend feed schema used in the previous example, read up on how that works, as you will see they sort of turn SQL on its head a bit, to make it more flexible and deal with these shortcomings.

What if it is the difference between your schema working under high transaction rates or not? Or, the difference between buying much more database hardware and having smaller shards to avoid index contention. (which, is $$)

Facebooks mysql architecture (at least used to, likely still is) based on this: https://backchannel.org/blog/friendfeed-schemaless-mysql

Note the simple schema, and lack of FKs.

FKs are rarely present in extremely high transactions per second systems that operate on the same few tables. This is due to index contention and locking.

I say this with lots of experience working on different production systems that see hundreds of thousands of transactions per second. I have yet to see one arrive at these kind of numbers using foreign keys, unless it's something like a giant shared hosting platform, that is operating on hundreds and hundreds of different tables. (therefore, less index contention)

Often, in these shops, data correctness is not validated in realtime in this way, but often in a way that is not in the critical path of answering queries. (more like, eventually consistent). Some places have entire teams for this.

To your point on correctness, my experience ranges a lot in areas where correctness can be eventually consistent. For something like healthcare or banking, you would rather spend the money on way more hardware, because you can't afford correctness to be off. However, with things like globally scaled social apps, this is just not the case.

Most people tend to still use Oracle in those situations. Which is legions slower , and legions more expensive than mysql or pgsql.

mysql is good for very high transaction rate platforms, that mostly rely on simple features. for this, it generally outperforms most of its competition in the traditional RDBMS space, and why companies like twitter and facebook use it. mysql likes simple, well designed queries.

postgres usually outperforms mysql for more complex operations, but is not as fast as mysql for simple ones.

sqlite is really only appropriate for things like mobile or desktop applications or things with generally low concurrency requirements.

i would be careful throwing the baby out with the bath water in your dismissal of mysql, but thats just my opinion:)

can you shed some more detail on that apple uses triggers with sqlite? that is interesting to me, and would like to learn more.

furthermore, foreign keys are not performant at mass scale on both pg or mysql or any traditional RDBMS. if your trying to do several thousand ops per second, the vector of index contention greatly goes up if there is FKs littered all over your schema.

nosql or sql large platforms almost always have some amount of work always ongoing to clean, shuttle, and maintain data integrity.

that doesn't make me not a fan of them; for lower transaction rate applications ( which most probably are ), they are a small time investment to have some sanity checking. but it's a right tool for the job thing.

this is yet another reason why people dislike FKs in best practice stuff.

Edit: Hi down-voters. Curious to hear why I'm being down voted and possibly be offer a rebuttal?

I like a lot of these very much and agree. Thanks for posting.

some great advice already posted.

try to not get to lost on where you are and how big of a delta to where you envision it is that you want to be. slow down if needed.

Try to enjoy where you are and master it. give your self credit at the level you are at. be proud of your code even if others are not kind. strive to make it better. always be improving.

be pragmatic. don't get lost in the weeds of politics, status, or any specific sort of rabbit hole that you won't learn from. if you aren't sure whether you will learn from, you probably will.

someone posted recently. if it's not a hell yes, then it's a no. I really like that. don't take on too much.

anxiety can suck. take it one day at a time, and learn to get the courage to ask questions when needed and practice the art of asking questions. it will be invaluable.

if you can find something passionate that excites you, remember this moment. occasionally refer to what makes you passionate and recalibrate as needed. if you find no passion, maybe take a break and revisit later.

good luck!

Oh man, I can relate so much its painful.

I share the opinion of the parent comment, pretty much exactly.

Some of my comrades call this a layer-8 problem. (hint: there is only 7 technology levels, 8 is the human one).

One story in particular my firm was hired to come into a startup that had failed to scale, both technology wise, and personnel wise. They had hired up to 25 engineers, hoping to fix their stability issues, and almost going bankrupt doing it. I am at no liberty to say which company this is publicly unfortunately.

It was stressful, but you can't take things personal. You have to put aside feelings, to get useful data out of these people to make the platform work. You can't possibly care about someone's ethics, approach, and often even coding style on these missions. The goal is to try and not piss off as many people as you and, and go ahead not worry if you do have to piss someone off to get the job done, and not lose sleep at night if someone does not get along with you.

The end result was that they had to shed, through various reasons the great majority of their internal team. We stabilized things and bought them lots of time, while they slowly brought in new senior tech management and rebuilt their internal team from the ground up.

It was a multi year affair, and involved working on over 12 codebases and consolidating applications from 3 different hosting providers into AWS.

They got very close to running the ship into the ground. If you think staying up late and pulling the occasional all-nighter is unhealthy, or having a job that has extremely high expectations and leave you no time for a personal life is bad, this is about one hundred times worse. Since my team is small and highly skilled we can get a lot done in a short amount of time, and occasionally we are terse even with each other. But the amount of sleep deprivation that comes with a task of gargantuan size, where your dealing with hundreds and thousands of requests (sometimes per second), the company is going for broke, and a single code change can improve monetary situations in instantaneous, tractable ways, it gets super intense.

You have the CEO, the COO, the CFO all breathing down your neck. One day they see light at the end of the tunnel from fixing the currently broken problem, and then the next day, you discover another codebase lost in git that powers commerce for android, is starting to experience issue, and you don't even know where to find credentials to log into its production systems since it was setup by some employee in the middle of the night a year ago that is no longer there.

I can go on and on and on. But honestly, please don't read this as a recommendation. Being a digital mercenary is fun in your 20s, but it got old quick. Of course I still do it, but I have a much healthier way of saying NO, more often now. You can make a very lucrative living doing this sort of work, but its hard to earn the reputation to get these clients, and you may end up forgetting what your family looks like by the end of a 2 year job that is 365/24/7.

The story did have a happy ending though. The company does well today. Extremely well. A new era of management has come in over the last year, and I think everyone learned a lot. They are a household brand and I hear about them in the news it seems like monthly.

Cheers

+1 for gobyexample that is my favorite resource, especially once you have broken ground, and are somewhere in-between having all the basics of the syntax mostly mastered, but some of the tidbits of the standard library not yet mastered.

Would you agree that the TL;DR of this is ultimately, since things are so easy right now, you won't learn skills that you pick up only when things are less easy?

Not sure where I see the mistake. Sort of reads like its a mistake to not get experience from having things go badly?

How would you fix? The bullet points at the bottom, like "build good products" are pretty vague and don't really give the reader much.

I can't imagine some of these younger entrepreneurs don't want to "build good products" and "building teams", even if they have a lot to learn in those departments with regards to weathering bad times.

+1.

I love that the android store does not make you wait.

Having said that, I hate Android Studio, and Eclipse, and I hate the android simulator too.

It makes the development process slower, feels clunky.

To each their own, of course.

Can you point to where this is happening more than the after mentioned over-sensitive, reductivist prima-donnas issues? ( I mean in the context of our industry )

Dongle Gate / Pronoun Gate / Opal Gate... whats next?

Let me guess: I'm an asshole for asking for proof.

Sigh.

> But it looks like you wouldn't

By your definition of toxic, your absolutely correct. With my definition of toxic, I would.

My definition of toxic includes racism, harassment, and misogyny. I feel like most people agree those are toxic, but I guess it is what else gets added to the list, and is it a suggestion, or something we enforce.

The more things that are enforced, and the bigger this list gets, the more this feels the opposite of simple, and not very go-like.

OpenBSD is also known for having some of the most secure code around.

I hear you, I really do.

I wish I had not met so many brilliant people that have the linus attitude. I would say maybe linus influenced them, but they are both on the windows and linux sides.

These people I continue to work with because they have taught me so much. They have been hard on me when I have been wrong and they have mentored me. I certainly would not be where I am if I did not grow thick skin.

However, I would definitely draw the line if I was ever harassed or was in a toxic community. I never got into IRC or Python. Maybe thats the key?

Linux, on the other hand, I don't classify as "toxic", overall, do you? I do occasionally read the LKML ( I don't subscribe ) and I have certainly seem some edgy behavior there, and times I think its overboard. Opinionated? Check. Intimidating? Check. But toxic?

It's really hard to speculate how many people have avoided working with linux because of this. There is certainly other communities such as FreeBSD, OpenBSD, etc. They seem to not have anywhere near the traction linux has, which would lean to indicate that what we are talking about did not hinder the success of linux, or prevent people from contributing to it at large.

Maybe it's because I do not use IRC hardly ever?

I have worked at 3 extremely well known technology companies, 3 start-ups, and had dozens and dozens of consulting projects. I have managed teams between 3 and 40 people, co-ed teams, and have served all kinds of engineering roles. (I simply say this, as I do get around quite a bit, not trying to say anything other than that).

Sure I have seen the occasional issue both online and in real life. But they don't seem specific to a programming language, it's usually one person out of line and the immediate surrounding community (employer, or forum) handles.

Maybe this issue is not as wide-spread as people think? Would love to hear reports of toxicity in the golang community specifically.

Or maybe people are in fear, and this is a preventative action?