Incuriosity Will Kill Your Infrastructure
yellerapp.com
Incuriosity Will Kill Your Infrastructure
1–10 of 32 posts
Re: Incuriosity Will Kill Your Infrastructure
#2Embedded software medical device developer here.
I once worked with a hardware engineer that would verbalize his thought process very explicitly, as we worked in the lab.
He would say things like: "Ok, I'm about to let the target out of reset. I expect to see the I2C bus controller initiate a master read of address 0x80."
Then he would do it, and look at the oscope, and see if his expectation was confirmed.
If it wasn't, or was fishy in any way, he'd say something like "OK, I have a mystery. I expected to see , but I saw instead. I'm investigating this before I go further."
So, you get the drift.
For this guy, the rule was "NO MYSTERIES."
Working with him was a fantastic and valuable experience.
Re: Incuriosity Will Kill Your Infrastructure
#3The bit about how Riak resolves concurrent writes sounds backwards. As far as I know, it's last-write-wins by default. You need to opt into storing all the writes via allow_mult.
Re: Incuriosity Will Kill Your Infrastructure
#4Not related to the post, but after going to the main Yeller page, I noticed that at the bottom one of the features listed is "HTTPS Everywhere (we don't even allow HTTP over our API or website)", yet the site is not over SSL at all. In fact manually entering HTTPS in the URL shows that the certificate is not valid.
Re: Incuriosity Will Kill Your Infrastructure
#5Not just your infrastructure, your code base too. I've seen a lot of developers practice what I call "debugging by superstition," where they make random changes until it appears to work. I prefer to keep digging until I understand. Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different.
One benefit of experience is that you gain a better intuition about your hypotheses, and you know how to more quickly devise "experiments" to test them. Also if you know more things in depth (because of prior digging) you don't have so many rabbit holes to explore.
Another benefit of waiting until you understand is that you don't make bull-in-a-china-closet edits to unfamiliar code. As a freelancer I have a strong bias towards adopting the style/patterns/architecture of whatever code base I'm working in. I wish more people did this! More often programmers skim through some code and start making changes, without trying to learn why the code is how it is or what other parts of the system need it that way.
Since this is the Internet I feel compelled to add: of course moderation in all things.
Re: Incuriosity Will Kill Your Infrastructure
#6Not just your infrastructure, your code base too. I've seen a lot of developers practice what I call "debugging by superstition," where they make random changes until it appears to work. I prefer to keep digging until I understand. Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different. One benefit of experience is that you gain a better intuition about you…
[deleted]
Re: Incuriosity Will Kill Your Infrastructure
#7Not just your infrastructure, your code base too. I've seen a lot of developers practice what I call "debugging by superstition," where they make random changes until it appears to work. I prefer to keep digging until I understand. Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different. One benefit of experience is that you gain a better intuition about you…
>Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different.
As Adam Savage [1] says, "The only difference between science and screwing around is writing it down."
I don't follow this process for every problem I encounter, but when I have a really intractable issue, where nothing I've thought of seems to work, I start a "lab notebook" (usually a few sheets of printer paper). I write down all my assumptions, and start designing experiments to test each one in turn. It's a fair amount of overhead (which is why I don't use this approach for everything), but when all else fails, the scientific method powers through.
Re: Incuriosity Will Kill Your Infrastructure
#8Embedded software medical device developer here. I once worked with a hardware engineer that would verbalize his thought process very explicitly, as we worked in the lab. He would say things like: "Ok, I'm about to let the target out of reset. I expect to see the I2C bus controller initiate a master read of address 0x80." Then he would do it, and look at the oscope, and see if his expectation was confirmed. If it was…
Aside:
I'm a biomedical engineer by way of Hopkins and would love to be able to ask you questions about medical device development.
If this is something you'd be interested in, what's the best way to reach you? Conversely, my contact info is in my profile description.
Re: Incuriosity Will Kill Your Infrastructure
#9So what I want to know, is, as per all the recent agile/scrum discussions - how does the modern "do sprint planning/commit to a number of sprint points to do/tasks to work on/be the product manager's monkeys" align with, "you saw something that's probably representative of a major problem in your system, but stopping what you're doing to investigate it will kill your velocity, and make your team's statistics look bad"?
Re: Incuriosity Will Kill Your Infrastructure
#10The bit about how Riak resolves concurrent writes sounds backwards. As far as I know, it's last-write-wins by default. You need to opt into storing all the writes via allow_mult.
allow_mult has been enabled by default since at least 2.0 - http://docs.basho.com/riak/latest/dev/using/conflict-resolut...