Threads for tikitu

  1. 6

    The up-front-design complaint is bizarre: it’s like he’s unwilling to contemplate refactoring (but only for these particular language features).

    Also, I can squint and see the possibility of a meaningful discussion about the tradeoffs involved in Swift’s exception handling and Kotlin’s open, but marking nullability is such a simple win I’m really amazed to see him complaining about it.

    1. 1

      Which is ironic since he’s a frequent proponent of refactoring.

    1. 6

      I feel like this will surprise nobody, but then I realise that it would have surprised me two years ago, so here are mine:

      • Github PRs; rigorously tidied and rebased before review; integrated with CI tool (jenkins) and task tracker (jira).
      • Related: rigorous review (github tooling again).
      • Pairing (I work remote, Screenhero is fabulous). Pairing during review, especially when it gets interesting.
      • For iOS dev, Swift is bringing in a bunch of ideas that functional folk will recognise. I’ve particularly benefitted from making immutability a design goal (wherever possible).
      • RSpec-style tests with arbitrarily nested environments, and tests as small and expressively named as possible.
      • Writing tests so that someone else can read them, understand what they’re asserting, and agree that the assertion is business-logic-correct. (This seems simple and obvious. It isn’t!)
      1. 1

        Whenever I see this kind of advice I miss the counterbalancing nuance: make sure you don’t let the little functions you extract become part of your published interface. You really don’t want your colleague importing one of your helper functions in their project!

        1. 4

          I still don’t understand how people can routinely put back code into a master branch without ensuring that it even builds correctly, let alone functions as designed. When an accident happens and you break the build, or the software in general, it seems prudent to back the change out of the repository until you can understand it. Whatever the mistake was should be understood, so that you (and your colleagues) can learn from it and avoid it in future.

          Mistakes can always happen, but negligence is simply not cricket.

          1. 4

            “I still don’t understand how”: a blameless postmortem is an interesting tool to try to find out. The idea is that things that in hindsight look negligent might have seemed perfectly sensible at the time. Finding out why they seemed sensible might show gaps in tooling or training. (Eg. tests were run but not on exactly the changeset that got merged; tests have been failing for engineer X for weeks but she’s ignoring them because they pass in CI; etc.)

            GitHub has a CI-integration “protect this branch” feature: you can configure master so that a PR can only be merged if a particular CI check has passed on the branch being merged.

            1. 2

              I agree wholeheartedly that it is important not to lay blame (or worse) for mistakes. Doing a post mortem analysis of mistakes is a crucial part of avoiding repeating the same mistake over and over; to ignore the problem is to become negligent.

              If you run the tests on a patch that is not the same as the one you eventually merge, you didn’t really run the test. Discovering that this is true, and understanding that even small changes can result in unanticipated defects is an opportunity to take ownership of, and learn from, a mistake. To continue routinely putting back changes where you did not test the actual patch is, subsequently, negligence.

              If the tests routinely fail on your machine (but not on others) and you ignore those failures without understanding the cause: that’s negligence as well. Every engineer in a team is responsible for the quality of the software. This is a core part of avoiding blame games – if everybody owns, analyses, learns from and shares their mistakes, nobody need point upset fingers at others.

              1. 1

                Certainly the blameless postmortem idea is only going to work if you do something with the findings. If the kinds of mistakes you’re talking about carry on happening regularly, then yes you have a problem.

                People will still make mistakes, though. That’s the nice thing about a tooling solution like that GitHub configuration: a whole class of mistakes simply can’t happen any more.

            2. 3

              For this reason, I think more version control systems need to make an easy, visible revert part of their core functionality.

              1. 3

                Where I work, it usually happens due to portability. Someone checks in code that builds fine on their preferred dev platform and assumes it will work on the others. We have an abstraction layer that helps with differences in the system libraries, but things like mistaken capitalization in an #include will work on Windows but not Linux. Conversely the GCC linker is more forgiving about mixing up struct vs. class forward declarations than VS.

                1. 1

                  Me too, the most common portability isssue we have is wchar_t = UTF-8 vs UTF-16.

                  1. 1

                    Yeah, developing for more than one platform can make it much more tedious to make sure your code is tested before it goes back. If this kind of failure happened more than once or twice, though, I would probably consider adding some kind of #include case check tool to be run out of make check. We do this already for things like code style checks.

                    You could conceivably make it relatively easy to install the checks as a pre-commit hook in the local clone via some target like make hooks. Pushing code to a feature branch to trigger some kind of CI build/test process before cherry-picking into master could help as well.

                    1. 1

                      I had close to a dozen build failures in the space of an hour because someone built live-environment integration tests into the CI test process, and they depended on a dev service that was down. “Fixing” the build entailed rerunning it unchanged once the depended-upon service had been restarted. It has always been my experience that broken CI builds are due to unforeseeable problems or circumstances outside the developer’s control, not a lack of due diligence on the developer’s part; so these “build-breaker shaming” devices seem incredibly counterproductive to me.

                    2. 1

                      I had it happen when I changed to a job where I had to use a different IDE from the one I was used to. I was used to making the kind of change that would show up immediately as a failure in my IDE if it was incorrect; if not, I would habitually commit to master, confident that it would work. Running a command-line build or unit tests was simply not justified in terms of the cost given the level of confidence I tended to have in such a change. With the new IDE my confidence was entirely misplaced and I broke a lot of master builds until I adjusted.

                    1. 1

                      What I see is: a negotiated solution, CI green, PR on track for being merged.

                      LGTM!

                      1. 3

                        Related idea (the “spark file”) here: https://medium.com/the-writers-room/the-spark-file-8d6e7df7ae58

                        You keep a document with all the hunches & half-baked ideas that come to you (the 100). Periodically you scan the whole file to find something to work on (the 10).

                        1. 1

                          A very little Swift snippet that I was unreasonably proud of. Note that the title is false: you can’t add stored properties in Swift extensions, but this snippet shows you something that’s functionally equivalent.

                          1. 4

                            I’ve never worked for a single-site team, so in practice I’ve found there is a remote-work aspect to my job. I’ve had a better experience with satellite workers than multi-site teams, and would prefer remote work if the organization was remote-first. The technology for remote work has been around my entire career. The culture hasn’t.

                            I wonder if remote-first organizations are stable, however. There are a lot of advantages to being on the same site. I’d expect people in a remote-first organization to naturally migrate to working in person because of those advantages.

                            Does anyone have any relevant experience with remote-first organizations?

                            1. 2

                              Our org is not fully remote-first, but I’m one of several fully remote members, so say 50% relevant: we are so geographically distributed that “migrating to working in person” would mean literal migration, or a lot of hiring churn. It’s hard to imagine it happening incrementally without an explicit policy decision (“e.g. we will stop hiring remote”).

                              1. 2

                                I expect your situation is far more common than remote-first work. It’s what I kind of expect to see, honestly. What tensions do you see between your remote workers and the site teams? My best remote workers call or chat pretty frequently just to catch up. My worst remote work experiences have my peers in such different timezones they’re difficult to coordinate with.

                                1. 3

                                  Tension-wise I think I can only echo common wisdom: it’s harder with people many timezones away (limited overlap) or when people don’t respond quickly to e-prodding (mail, chat, etc).

                                  One trap we’ve seen is over-specifying: because you want e.g. a design concept to be remote-friendly you write down all the details that went into it, but then as the design changes over time you have to maintain that ever-growing document. I think the solution is to prefer collaboration over handoffs but that’s somewhat aspirational for us at the moment. (I imagine this can be a problem in any team, but I think our remoting exacerbates it because it raises the difficulty of the collaboration option.)

                              2. 2

                                My company isn’t remote-first, but has two big offices in Cincinnatti and Arlington, along with a decent number of remote folks in other places. I am, however, on a remote-first team with only a couple of people who work from the office. This arrangement has seemed pretty stable, and our team is noted for being quite mature and productive.

                                1. 2

                                  Yeah I’ve worked with a small company that was entirely distributed/async. Five people in each of Auckland (self), Tokyo, Malmö, London, and somewhere on the east-coast US.

                                  We met up several times over the course of a year, but mainly for social gatherings than really to work per se. I don’t think being in the same place really added much in terms of productivity (it probably decreased it) - it was just fun to hang out together occasionally.

                                  More companies need to organize themselves in this way IMO.

                                  1. 1

                                    Was your hiring process different in any way to account for the unusual structure of the company?

                                    1. 2

                                      Hires were just pre-existing connections, but that’s a bit of an atypical case because the company was (and still is) so small. But small can be good! You can often get pretty far with a handful of people.

                                1. 5

                                  I just started S by Doug Dorst and J.J. Abrams, which is weird enough to be worth pointing people at. It comes in a box, and you get a hardcover novel (The Ship of Theseus by VM Straka) completely covered with handwritten annotations that tell their own story – not all in page order, either – and a whole lot of “feelies” (postcards, handwritten notes, photocopies) slipped into the pages. Too early to tell if the writing is anything worthwhile, but the thing as a whole is a beautiful physical artefact.

                                  1. 16

                                    Nice! May I suggest, though, putting the user avatars to the left of the username rather than the right? That way they will tend to align vertically (typically the text to the left of username is fixed, e.g. “by”, or the comment-thread collapse widget) which makes for easier scanning and less distraction from the irregular placement.

                                    1. 4

                                      May I suggest, though, putting the user avatars to the left of the username

                                      I would tend to agree! Here’s a shoddily put together example with incorrect spacing but you get the idea.

                                      1. 10

                                        Ok, I moved them to the left.

                                    1. 2

                                      I’ve had very good experiences pairing with someone much more experienced than me: I found it a very effective teaching / mentoring technique. (I also believe the senior got something out of it: having to discuss things with me as well as with the compiler did sometimes give them insights they probably would have missed if working alone.)

                                      1. 2

                                        The Matasano crypto challenges got some good press, and seem nicely structured (I stalled after the first set: we had our first baby). Now online: http://cryptopals.com/

                                        1. 6

                                          I’m the only remote programmer in a team of 5, company of 20. I’ve been off-site for a year now, and we’re all happy.

                                          One very important point: I moved away from the office location after several years on the team. Hiring your first remote employee is likely to be much harder than moving an existing employee to remote: you have to build up the working relationships at a distance.

                                          Tools we’re happy with:

                                          Hipchat for IM (it bounces to mail if recipient is unavailable, notification options are pretty good).

                                          Google hangouts for morning standup (substitute skype/hipchat/your-favourite-alternative). A laptop is fine for this, but both camera and mic will be quite directional and limited-range: either get people to jump to right in front for their bit, or buy some slightly more expensive hardware for the office (a cheap mic that you hand around already makes a huge difference).

                                          Google docs plus a voice (optionally video) channel for design discussions: the fact you can see each others' cursors in the doc means you can “point at things” which has been really handy.

                                          tmux for working together on servers (stuff where in the office you’d have one person driving and one watching the same screen, but the watcher might want to take the wheel sometimes). This also works well with a separate voice channel open.

                                          Stuff we’re missing (i.e., we feel like we want it, but not so urgently that we’re willing to pay for it):

                                          Shared presence in code: screen-sharing is one-way, tmux is fiddly, there’s probably a good option out there but we don’t know it (yet). We get by with screen-sharing (and annotated pull requests for code review).

                                          Shared sketches/diagrams, as you’d use a whiteboard for in person.

                                          Habits and other “soft stuff”

                                          Make eliminating communication friction a top priority. It is Not Ok if you’re prevented from getting something you need, because Tikitu’s internet in Greece is fried (or gchat on the standup machine won’t unmute, or the firewall on the VC server is rejecting connections from Eastern European IP blocks, or whatever). If left to grow, the smaller irritations of this kind will expand into a painful disconnect between your remote folks and home folks.

                                          Timezones: a small timezone difference can be positive (a couple of hours of uninterrupted work before the office gets started); a big one is a pain. (I worked for six weeks with a 12-hour time difference, joining the morning standup at 10pm. I don’t recommend it.)

                                          The remote folks are going to have to push a bit for remote-friendly behaviour from the home team. That might be easier if the home team also get a bit of “remote” (out-of-office) experience (a few days working from home, or similar): there will be things the home folks simply don’t notice are sticking points until they experience them themselves.

                                          Regular trips home: I do every 2 to 3 months, ymmv. Keep a list of things that you’re putting off for in-person, and make sure it doesn’t get too long.

                                          Your remote folks will miss out on the side discussions, that’s unavoidable (until there’s so many remote folks that the side discussions happen online…). But make sure to put the results of all side discussions somewhere they can see them. This can be a real culture shift; it’s paid off for us in other ways also (in particular, more documentation of intent and the reasoning behind decisions).

                                          1. 2

                                            One last pro-tip: the remote folk should try to avoid this situation, if at all possible: https://twitter.com/tTikitu/status/428690448559779841

                                            1. 2

                                              That’s a good protip, “Remote Workers should ensure all cabling is protected from livestock” – I’m going to write that one down.

                                            2. 2

                                              We’re using TeamViewer and tmux for Pair Programming but we’ll start experimenting https://floobits.com/ for coding. https://talky.io/ uses WebRTC technology for screen sharing but, unfortunatelly, does not allow remote control.

                                              1. 2

                                                What kind of problems have you had with tmux? We used it every day at my last job and found it to be rock-solid.

                                                1. 2

                                                  Not problems with the tool itself, but setup/workflow stuff: can I ssh to your box? (Oh, not since your last update. Ok.) Let’s look at it on staging. We need to rebuild the branch there? Ok. Now we’re good to go… wtf, someone’s customised the keybindings? Etc. Doesn’t help that half the team is using IntelliJ (PyCharm) and half vim.

                                                  For work on the servers (as opposed to pair-programming) it’s been a near-complete success; the only thing I’d like to see would be two side-by-side independent panes, so both can work simultaneously while keeping up with what’s happening.

                                                  1. 1

                                                    Our biggest problem are the graphical IDEs/text editors that our team members use (PyCharm and SublimeText). But the https://floobits.com/ has plugins for both (and for vim, etc).

                                                    1. 1

                                                      Gotcha; we had similar awkwardness around where to connect to–when I’m at home I can just set up port forwarding, but when I’m at a coffee shop or tethering from a park, that’s not gonna work.

                                                      One solution that worked fairly well with port forwarding was to have .ssh/config fragments checked into a shared git repo so you could document the pairing username, port, and hostname you used. People pull that in and then can just run ssh yourname and be off to the races. I really wish OpenSSH would add support for a ~/.ssh/config.d dir though: https://bugzilla.mindrot.org/show_bug.cgi?id=1613

                                                      Other things that have worked well: http://tmate.io and doing development on EC2 nodes.

                                                      1. 1

                                                        Seems like it might be a good idea to use a VPN or ssh port forwarding to a VPS so that everyone uses the same stable rendezvous point?