Threads for danmidwood

  1. 1

    Team incentive systems should take these values into account, rewarding U.S. developers with money and French developers with time off.

    I would have thought the opposite a better strategy. Reward time-poor Americans with time off and time-rich French with money. I’m an American developer and I would much rather have more time off.

    1. 2

      I imagine it’s more to do with taking a single company offering and making it match the existing-company culture of the worker’s locale. So if the company is a US originated company and offers just two weeks of vacation then the employees outside of the US may prefer to sacrifice some of their income to get back up to vacation parity with their local peers. Whereas in the US it’s already the normal and assumed that money would be greater appreciated

    1. 21

      The worst things in this article are not the “anti-patterns” but the author’s belief in a “meritocracy” (as if skill was the only thing rewarded on in any company, and not biases) and the rejection of a candidate due to “cultural fit” (a great way to form a gross monoculture) - I really hope the software industry soon learns to think of these things as awful ideas.

      1. 12

        Sometimes cultural fit is just a nice way of saying the person would be toxic to the team. I’ve seen it more than a few times with the title-obsessed.

        1. 4

          How could you both have a meritocratic environment and reject people based on a perceived culture fit?

        2. 4

          It’s strongly normative towards a very particular method of software development. I don’t think that it’s useful to generalize from that, as I’ve worked with very productive people who do not share the “roll up your sleeves and apply your mind-bursting sagacity by working 27 hour days” mentality.

          1. 1

            Isn’t culture by definition singular ? How can a company have more than two cultures for developers ?

            1. 5

              “Monoculture” doesn’t mean “one culture.” It means “a culture composed of only one type of thing.” The term comes from agriculture.

            2. 1

              The authors use of words are unfortunate here, both “meritocracy” and “culture fit” are now bad words in the tech industry (and for good reasons that I’ll save for another comment on another day)

              But reading the article, it’s clear that the author is not advocating these in the way that we read them. In the article:

              • Meritocracy - valuing people over job titles, particularly with removing one of the bigger biases out there
              • Culture fit - rejecting someone that is title obsessed, someone that thinks a bigger title means more power

              Both of these seem reasonable and I don’t see anything else in the article promoting meritocracy or to suggest that he’s building a monoculture.

            1. 2

              There’s more information and a link to a recording1 of the talk on the codemesh site here:

              1. 3

                I’ve been learning Go to support some client work. There are plenty of things I don’t like about the language already, but a few that I do and it’s been an interesting enough challenge so far.

                As part of the challenge I’ve been looking at interesting libraries written in Go, so far it’s just been this raft implementation but it’s already proving quite interesting. I’m on the lookout for more if anyone has recommendations then please let me know.

                1. 3

                  A good rant, I mostly agree. Methodologies are not pointless, they (the same as “Best Practices”) are often evolved under certain circumstances and are appropriate at the time. To ignore them is ignorance, but to embrace them fully as the-one-true way is ignorance combined with drone-ism.

                  Usually the things that have been accepted as methodologies and the like are there for a good reason, but that doesn’t mean they’re applicable universally. Accept them, learn from them, but always try to fit things to your environment, improve, and make things better.

                  1. 5

                    I’m an advocate for TDD. But, it depends on the situation.

                    TDD is great at providing almost instantaneous feedback. When I first started programming (Java) I worked at a company where we had no tests, our codebase was set up in a way that did not accommodate tests, and it led to an extremely slow feedback loop. I remember times where I would make changes, spend many minutes rebuilding the project, testing it manually, and then hit a problem that I hadn’t anticipated and have to go through the whole thing again.

                    Later I moved on to another job, still Java but where things were TDD’d. It shortened the feedback loop by many multiples and provided a huge improvement in productivity. This is the “faster” that TDD proponents talk about.

                    More later, I moved away from Java into FP languages, and particularly REPL driven development. This is the ultimate feedback loop. If I’m ever unsure about something I can eval it and know right away. But, this led me to writing less tests. Right now I’m working on capturing my REPL experiments as tests, because…

                    TDD isn’t just about the feedback loop, the tests also leave “contracts” for future people working on the same code. When I encounter a large codebase that is covered in tests I have the confidence to go in and make changes, when there are no tests I don’t have that same confidence. Of course, passing tests doesn’t always equal everything-is-fine, but usually it does, and that’s a great thing.

                    1. 1

                      About capturing REPL experiments as tests: I use – it’s for Emacs and (mainly) Python. It’s actually a tighter feedback loop than a REPL gave me, plus persistent by default.

                    1. 3

                      For the last four months I’ve been mostly not-developing as I’ve been traveling around, seeing family, friends and a few other things. I’ve stopped that for now and found a place to live for the next month at least, so it’s time to get back into a normal type of life. And it also means I have something to post here.

                      I spent last week on a few things:

                      • Firstly, trying to find some work, I have an interesting lead now so I’ll see where that goes.

                      • A side project with a designer friend of mine, it’s a simple web app in the Buffer vein of things, built with Clojure and plain React.js (no Clojurescript / Om in this project)

                      • Working through Understanding Computation, I read it a while ago but I don’t feel like I really absorbed it. I’m going back through, writing out and experimenting myself with all of the code in the book.

                      1. 2

                        The thing I find most difficult is “choosing” what to listen to, it’s something I don’t want to have to think about when I’m trying to work. I tend to fall back on the Resident Advisor podcasts [1], the podcasts are mixes that last ~1hour so it’s easy to line up a few and not have to think about it. It’s electronic music covering a wide range of types, with minimal vocals and very easy to feel and get into without being distracted.

                        Another thing I’ve found recently is Spotify’s “Your Music” feature, using that I’ve been able to create a large collection of albums that I used to own (and some that I’ve found since then), with that I know I can quickly switch to the app, select something, hit play and get straight back to work.


                        1. 1

                          Is James mickens someone who is big in monitoring? I’m assume based on this mostly being titled w his name that he must be.

                          1. 3

                            I don’t know. I know his name mostly from his Microsoft Research articles, they can be pretty humorous while still also having useful content. You might have read some, the The Night Watch paper on systems programmers particularly was widely spread and quoted on Twitter.


                            1. 1

                              Until recently, he wrote the funny “everything about software sucks” columns for ACM. I imagine this post could have used the satire tag.

                            1. 7

                              This is niiiiiice.

                              I read a lot of code everyday and I don’t want to clone every single repo I poke into. I hope Github takes some UI/UX ideas from this.

                              Being able to bounce between different files in the same namespace in a Haskell library without bouncing “out” of the file into the directory and then clicking “into” a different file and instead going directly to the file I want from the side panel is great.

                              1. 5

                                Github’s keyboard shortcuts can help here, hit t and start typing the name of the file you want to browse to.

                                Of course, that’s predicated on knowing the filename you want to view, but when you do it’s a real click-saver

                                1. 4

                                  I use vimium, there’s a conflict there.

                                  1. 2

                                    To view all of GitHub’s shortcut keys, press ?, then click the ‘Show All’ link. They are quite similar to those GMail uses for searching and navigation.

                                    Some other useful shortcuts:

                                    • l to jump to a line
                                    • w switch branch/tag
                                    • / search current repo
                                    1. 1

                                      Github became so much more useful once I discovered the t shortcut. When asked questions at work about certain parts of our codebase I now refer to the Github repository to search for a file rather than my possibly stale local copy of the same project. It makes quick references very accessible.

                                  1. 2

                                    Are CRDT counters idempotent? (Or, do CRDTs always have to be idempotent?)

                                    Because, I don’t understand how they can be. If they are and anyone can point me towards some writing or any implementation then please do.

                                    1. 9

                                      It depends. CRDT counters as implemented in Riak are not idempotent, but for good reason.

                                      If every client was an actor in a PN-Counter, and you wanted every game player of your mobile ‘phone game to increment the count, you would have a very wide PN-Counter (an entry per actor.) If these clients all read a CRDT from a database with a RYOW consistency level (or store their own writes locally, durably), then you can have idempotent counters, by dint of the fact that the merge function (the LUB) of a CRDT is idempotent.

                                      Carlos Baquero et al did some work around this limitation in this paper:

                                      In Riak, we bound the number of actors to be the replica vnodes for a data item. This means that many, many, clients send operations to Riak (inc/dec.) without changing the size of the counter. The downside is “counter drift.”

                                      If Riak receives an operation, and executes it on a vnode, but fails to replicate to W-1 vnodes, or if Riak succeeds, but the client never receives an “OK!” Then the operation is a partial success. This is indistinguishable from an actual failure from the client’s perspective. If the client resends the operation and there was a failure, OK! But if there was a partial success then we double counted. This is positive counter drift. If the user choses not to resend the op and there was a real failure, this is negative drift.

                                      How to make this system model idempotent is the subject of current work. Trivially, you can make an idempotent counter CRDT like this:

                                      • Client creates a unique ID for an operation (say {id: 100, op=12} means id=100, increment by 12)
                                      • A Set on the database stores this
                                      • The client can resend as many times as it wants, that id, op pair will only be stored once.
                                      • Set Union is idempotent.
                                      • Set insertion is idempotent.
                                      • Value of the counter is sum of all ops.

                                      If the client never re-uses the id, it can replay the op safely. Downside? That’s going to be a big set.

                                      I’ve seen implementations where an ID lasts for some period of time, and is then dropped. And so you keep a set of ids + some roll up integer per actor, and you’re idempotent for failures that last for some period of time, after which retrying will lead to drift.

                                      In general the update/mutate function on state based CRDTs are not idempotent, but the merge function is. If you send CRDTs between nodes in your system (including the clients) and you can always RYOW (either client local storage, or from a database) then you have idempotent operations.

                                      1. 2

                                        Usually they are not. At least the ones implemented by Basho for Riak are not.

                                        1. 7

                                          Yes, the operations performed over CRDTs are always idempotent. Riak’s counters (implemented here AFAIK) are state-based PN-counters, described in Section 3.1.3 of the Shapiro et al. CRDT techreport.

                                          Each actor (or client, in the case of Riak) maintains its own count of increment and decrement operations; upon read, these are merged to yield the current value of the counter. The idempotency isn’t that an actor can issue an increment multiple times, and only the first will be acknowledged; it’s that one actor’s impact on the counter is not applied multiple times despite repeated replications / merging of its state.

                                          If you do want actors to only be able to increment once, then you can build a CRDT counter comprised of two sets, one to track increments, the other to track decrements; getting the counter’s value requires taking the difference of the sets' cardinalities. An increment in “userland” would add an element to the increment set with a tag uniquely identifying the actor, likewise for decrements.

                                          (I don’t work for Basho, so perhaps someone who does can correct me if I’m wrong somehow.)

                                      1. 1

                                        I’ve been working on an open source project, a port of Argot SDK (Java IoT communications library) over to Javascript, primarily targeting Node but I’ve also added support for client side with Browserify. It’s my first major piece of Node work so it’s been a great learning experience. The under-documented repo is if you’d like to take a look.

                                        In the free time I’ve had, I’ve been working on an iOS game with a couple of people back in the UK. I’d like to share the url but our domain expired. So, maybe next week.

                                        And, in my free free time I’ve been learning Spanish (I’m currently in Ecuador), attempting to talk to people (most shopkeepers) and watching and attempting to understand a bunch of Spanish shows on Netflix. I’m still at the extreme basic level, but I’m learning and it’s good.