1. 9

    There’s a book about this: The Innovator’s Dilemma. It uses the term “disruptive technology” for what this article calls “grow-up” technologies, and has examples from other industries as well. (The term “disruptive” was then adopted by startup people to mean “breaking the law as a business model” or sometimes “clueless about how this industry works”.)

    1. 14

      I’m all for unionizing, not out of “unionize all the things”, but because I’m interested in how different power structures might effect different results: experimentation, if you will, but not at the cost of free association.

      I grew up in a family of public school teachers. I’ve seen unions mess up badly.

      1. 24

        My wife is a teacher in the public system and we both have mixed feelings about the union representing teachers. It does some wonderful things, but then goes out of its way to defend some absolute garbage people simply because they are in the union. And heaven forbid it if you have any critcisms of the how the union operates. Neither of us think it’s so much a union thing as it is the lack of care put into building a large organization since similar problems exist in companies.

        1. 14

          I’m not super-attached to the idea of unions, but it’s pretty obvious to me that we are getting exploited by the companies–especially startups–that we work for.

          I’m not sure that a full-blown union system is the answer, mostly because I trust the soft skills and systems thinking of engineers about as far as I can thrown them, but we need to start organizing as a class of labor on some basic things that keep screwing up the market for all of us:

          • Forced arbitration
          • Broad NDAs
          • Broad non-competes
          • Broad assignments of invention and other IP
          • Lack of profit sharing
          • Bad equity for early-mid stage engineers
          • Uneven salary systems

          Every company and startup gets some of these wrong, and few (if any of them) right, but because it’s accepted as “standard practice” we all end up having to endure them.

          I don’t think we can find a one-size-fits-all solution for, say, salary ranges or other more esoteric issues, but my belief is that those specific things enumerated above are both achievable and universally beneficial for developers. They would benefit both the folks that think they can be the smartest engineering in the company and somehow make out like in the 90s, and the lifers who just quietly and competently do their jobs and switch companies when it’s time.

          We need to push for them.

          1. 2

            “I trust the soft skills and systems thinking of engineers about as far as I can thrown them”

            I was a bit surprised to read that. I know engineers are infamous for falling short on “soft” skills but isn’t systems thinking supposed to be a forte of engineers?

            1. 2

              One would think so!

              In my experience the first thing most smart (note: not wise, just smart) engineers reach for when consulted with a misbehaving situation, especially involving humans, is a system. They have this idea that some intricate set of deterministic protocols and social customs will save them from the ickiness and uncertainty of dealing with other sentient rotting meat. They’re invariably wrong.

              Outside of dealing with other people in meatspace, my current work in web stuff has similarly colored my opinion of “systems thinking”, to the point where I basically don’t trust anybody to reliably engineer anything larger than a GET route backed by a non-parameterized query to a sqlite database–they tend to want to add extra flexibility, containers, config files, a few ansible scripts for good measure, maybe some transpiler to the mix to support a pet stage 1 language feature, and all this other nonsense.

              So, sadly, I’m reluctant to trust those folks who overengineer and underempathize to successfully build and manage a union.

              1. 2

                Engineers are famous for thinking that a new bit of technology could revolutionize systems which include human social behaviors.

                I’ve met 2-3 engineers in the past decade who I would call ‘systems thinkers’. I’d like to make it onto my own list, someday.

            2. 6

              I have on my reading list https://www.press.uillinois.edu/books/catalog/47czc6ch9780252022432.html, which talks about the self-organized unions in 1930s that preceded NLRB, and the ways in which they were more democratic and more responsive to membership.

              1. 1

                I eagerly await your synopsis of it and maybe I’ll pick it up myself. I enjoy your writing!

                1. 0

                  Taft-Hartley in the 1950s had a terrible effect on unions, partly by banning wild-cat strikes and boycotts both of which forced union leaders to be responsive to members.

              1. 11

                Great points made, but with an unfortunate false dichotomy holding it all together. There is a continuum here, and the same individual can occupy different places on it in different contexts. I suspect most of us do. I lean “pragmatist” by default, especially when I don’t know much about a project. When I know more about value propositions, stakeholders, and other risk/reward factors, I adjust accordingly. For personal projects, research, or greenfield work where I know it’s safe, I’m as much an “enthusiast” as anyone else.

                1. 2

                  It’s basically seasoning in the industry.

                  If you are purely an enthusiast at work even after many years, you are probably haven’t improved much.

                  I’m not saying that you shouldn’t be enthusiastic, fun projects are fun, but seeing the problem as a solution to a goal and be technical/scientific about it needs to be the priority of a programmer. Coding a little thing during the weekend, doesn’t necessarily have the weight of a production level project.

                  1. 0

                    It’s obviously a simplification (and I state that in the article), but for most people I think one or the other is dominant. In your case for work purposes you’re a pragmatist first, sounds like.

                    1. 1

                      Same problem as with “introvert/extrovert”. I guess you could argue that any given person is inherently one or the other, but if they’re being realistic while working their craft (socialization, in this analogy), they might just seem like an extrovert to any outside observer. Same deal with “enthusiast/pragmatist”. (enthusiast : pragmatist :: introvert : extrovert)

                      What I’m saying is: it’s just a feeling, and if someone doesn’t feel like they’re on one end or the other of the dichotomy, then its universality is broken.

                  1. 8

                    Note that this was reverse-engineered from Django docs; here’s a document explaining “here’s how Django decided to organize docs” without the reverse engineering— https://jacobian.org/writing/what-to-write/.

                    (Separately: I really love this particular writeup.)

                    1. 3

                      Did I get this right?

                      You argue that maintainable, well tested code (that takes longer than you have to make) versus untested, buggy, non-working code that you can get done on time is a false dichotomy.

                      You demonstrate this by providing an example of a situation where you chose to meet the deadline by producing software that doesn’t scale, doesn’t handle errors, doesn’t do what it’s supposed to do in production, and doesn’t have tests.

                      How does that show the dichotomy to be false? If anything, this looks like evidence supporting the dichotomy, and the fact that you were lucky to win VC money afterwards to get you a new deadline doesn’t really change the scenario.

                      You kinda the scenario difficult question by acknowledging that you really have very lax requirements. Yes, meeting a deadline is easy if the requirements are lax enough that you can skip whatever. Sometimes you’re actually required to deliver though. Say, a contract between your company and client? And that puts us back to square one. “I don’t actually need to do this stuff my customers ordered / boss assigned me to do” is not really an answer for most of us, most of the time. I don’t think so anyway.

                      1. 3

                        I think you may have misunderstood the point, so let me try to rephrase:

                        1. Deadlines are met by dropping features that aren’t needed to meet goals.
                        2. In addition to dropping features, you can also reduce “quality” in places where it doesn’t matter, in which case it isn’t really quality in any useful sense anyway. See Havoc Pennington’s excellent blog post on “professional corner-cutting”, emphasis on professional: https://blog.ometer.com/2016/05/04/professional-corner-cutting/
                        3. Saying “no” to your boss and customer in constructive way is hugely valuable. E.g. a good consultant gets paid way more than a freelancer, in part because of a willingness to say “no, that won’t solve your problem given your constraints, but maybe we can do something else.” Does well by employees too, so long as you work for reasonable boss and organization. See the link in the blog post for how one might do that as employee (https://codewithoutrules.com/2018/08/16/how-to-say-no/). For consulting, read/listen to some of Jonathan Stark’s stuff (e.g. https://www.ditchinghourly.com/6d93936e).
                        1. 1

                          I think I fully understood your point, which seems to be that you can sometimes get out of a hairy situation by moving the goalposts, and in particular, moving them in a manner that has you take the “deliver poorly tested software that doesn’t do what it’s supposed to” if you look at it from the perspective of the original (perceived?) goals. Even if you can move goalposts to such an extent (which I don’t believe to be always true), it does look much like you’re going with the dichotomy. And what do you do when you can’t redefine the problem and move goalposts? Do you wish the dichotomy away?

                          I don’t know, I feel this is like saying “oh, I don’t have enough time to do all my homework well. So I’m going to have to do a part of it well and skip the rest, or try rush it all.” And then you figure out the third option, don’t do homework at all, just try wiggle your way out of it by pretend you’re done and hope you’re not asked about it (make something up on the spot if you are?). That’s worked damn well in my past by the way. But sometimes you can’t move just move goalposts like that, and the dichotomy doesn’t disappear. From the perspective of whoever assigned the homework, I’ve either missed deadlines or delivered crap (or both) but they are none the wiser because I got away with it. Most of the time. ;-)

                        2. 2

                          “I don’t actually need to do this stuff my customers ordered / boss assigned me to do” is not really an answer for most of us, most of the time.

                          I think it actually is, I think it often isn’t considered as seriously as it should be. Maybe the developer is nervous about pushing back on their boss, maybe they really WANT to do it a certain way that feels better in their brain but they know they could do it a more simple but far less elegant way… a more short term, but deadline conscious way.

                          A lot of times, if you tell your boss / customer – “I think we can skip $X because we don’t need and it will help us make our deadline” the answer is going to be a boisterous “Woohoo, OK lets skip that, good catch $Person”.

                        1. 17

                          In the Python world people usually:

                          1. Store docs in docs/ folder.
                          2. Rely on readthedocs.org to autogenerate and host docs off of that git repo.

                          This is superior to github pages in that you can have multiple versions of docs tied to your releases. Not Python specific in any way, either, you can use the service for whatever.

                          1. 4

                            I had a colleague who when he was a newly minted programmer realized he wasn’t very good at writing lots of code quickly. So instead he focused on problems that required more thought and planning up front: frameworks instead of features.

                            Some of his colleagues are still doing the same thing they were when they started. He’s moved on to much harder and more interesting problems than churning out small features for a web app.

                            1. 38

                              I like that the blog title and the domain name are directly at odds.

                              1. 5

                                Headlines are hard. In the actual prose I say “almost always” :)

                                1. 14

                                  So… an exception to your rule? Check mate.

                              1. 18

                                If you haven’t clicked the article already, it essentially boils down to: if you’re not a proponent of CSS in front-end design, you’re a misogynist.

                                1. 8

                                  That’s definitely a strawman.

                                  1. 5

                                    That is very much not what it says. The argument is “both technical choices are valid in some situations, so many of the people who are arguing one side are doing so for sexist reasons.” You may disagree with that claim, but your summary is just plain wrong.

                                    1. 0

                                      definitely a good faith reading of the article, please continue to add more substantive insights like this.

                                      1. 0

                                        I usually peek at the comments before reading the articles, this time I didn’t and I paid for it… (with neurons)

                                        1. 2

                                          Derek! This post is super interesting and I hadn’t seen it until now. I’d worked on a similar idea about a year ago with a bitcoin-paying npm proxy server. The idea was basically the same: package developers could include payment information in the metadata and folks that use the projects would automatically payout to those projects.

                                          Although, I think OpenCollective’s BackYourStack has done a better job at creating a user-friendly system (centralized, over the traditional payment system).

                                          I’m not sure this fulfills OPs criteria for a compelling use case, but it’s great to encounter someone working on similar ideas.

                                          1. 2

                                            At the time there was push back from blockchain people complaining about blocks being filled up unnecessarily. These days Etherium might be a better, if somewhat more complicated solution.

                                            Traditional payment systems are designed o be confidential, which for this use case is a disadvantage.

                                          2. 2

                                            The argument seems to be “PayPal doesn’t have an API for this.” So the issue isn’t the centralized system, it’s just a missing API, and if they had it PayPal would suffice?

                                            1. 2

                                              The point of the blockchain approach is that proof of purchase is publicly visible; removing the need for the software developer to spend time any time confirming the sale.

                                              1. 10

                                                You dont need a blockchain. You just need a log, crypto, and 3rd-party checking. Schemes for “blockchain” functionality that just used logs with crypto have been around a long time.

                                                1. 5

                                                  More specifically I guess, Certificate Transparency. Every time someone wants a “blockchain” to publicly prove something, they actually want CT.

                                                  1. 1

                                                    I think this is correct. Although it’s very hard to trust Google on this specific instance.

                                                    1. 3

                                                      You don’t have to trust Google for anything. I mean, you can adapt the general scheme/protocol for any content (not just TLS certs) and trust whoever you want to host servers.

                                                    2. 1

                                                      That’s another good example of logging + crypto + checking.

                                                      1. 1

                                                        A CT is half the solution. A blockchain performs payment and public record keeping in one transaction.

                                                        1. 2

                                                          It does but it’s unnecessary. Fire off two transactions: one updates a key-value store that audit pages are generated from; one goes through payment system. Both are so efficient that similar protocol operations are done on 16-bit MCU’s in smartcards.

                                                          It’s also not clear that you want the payment and log handled by same systems with same privileges and admins. Splitting them up can mitigate some risk.

                                              1. 1

                                                I think that’s an abuse of Pool. The point of it is to avoid forking off a process for every task.

                                                1. 1

                                                  The while loop is just to make the race condition happen consistently; in real code you wouldn’t loop, so you’d only get the deadlock intermittently.

                                                1. 2

                                                  tl;dr: deflect and avoid saying “no” to superiors

                                                  1. 2

                                                    It’s more like, deflect and avoid an automatic “yes” to superiors.

                                                    Obviously you need to weigh input from organizational heads differently, they have a different context then you do (otherwise what’s the point of em’). They tend to have a broader context, you tend to have a more narrow and detailed context.

                                                    The superiors’ version of this advice is, don’t automatically override the decision making power of your subordinates, they probably have details that you don’t have. This article is full of good advice.

                                                    1. 1

                                                      That is very much not what I’m suggesting.

                                                    1. 2

                                                      I’m going to be honest here: I’ve been working around 35-40 hours for the last year and I am still incredibly burnt out. I think it’s the context in which I work right now, but I cannot seem to shake it. I’ve tried long weekends and I have a week off in about a month, but the workplace itself is slowly killing me.

                                                      I work for a huge company with very little ownership and a ton of politicking. I’m not cut out for that type of work.

                                                      1. 2

                                                        Time for a new job?

                                                        1. 1

                                                          Yes, I would tend to agree

                                                      1. 16

                                                        Option #4: Start a product business (the right way)

                                                        Did the author ever run a business?

                                                        The most realistic chance of working less than 35 hours is slacking off somewhere as a salaried employee.

                                                        1. 5

                                                          Slacking usually requires you to be in n office, so you’re still working

                                                          1. 15

                                                            This is where it gets philosophical. Sure you can’t go hiking or do parenting in that time. However people playing games, reading books, solving puzzles and even building entire parallel careers in their nominally work time aren’t unheard of.

                                                          2. 3

                                                            Exactly, when I ran my own startup, it was like working at 2 jobs. Always something to do, fix, research, discuss, plan, etc.

                                                            1. 2

                                                              It depends on the business, though. I know people with couple moderately-successful iOS apps where yes, they do some support nd bugfixing, but can do it on their own schedule and the money comes it “on its own”.

                                                              Startups are a particular kind of product company that is high-pace. But small-businesses can also exist.

                                                            2. 2

                                                              He did found a startup in the early 2000s.

                                                              1. 1

                                                                And it failed! Because we did it the wrong way. But Amy Hoy has done it the right way, and teaches how, which is why I linked to her stuff.

                                                                Also note that VC-backed startups are very definitely NOT the way to get decent working hours as a founder. It’s totally possible to work decent hours (<40) as an employee, as I’ve done at last three jobs.

                                                            1. 1

                                                              My visceral hatred for unpaid overtime helps make me a productive developer.

                                                              1. 3

                                                                Indeed.

                                                                Of course, now I’m imagining a software development methodology where the planning phase is called “The 2 Minute Hate”…

                                                              1. 6

                                                                Are you familiar with https://software-carpentry.org/? Lots of material you can use or reuse (and people you can track down and talk to).

                                                                1. 2

                                                                  I am not yet; thank you!

                                                                1. 3

                                                                  I’m sure I’ve mentioned this before, but I’ve bought several books because of your reviews. Keep up the good work :)

                                                                  1. 1

                                                                    Haven’t bought any yet, but really enjoying the reviews, yeah.

                                                                  1. 2

                                                                    Being able to work independently is much more important than technologies you know. If you can demonstrate:

                                                                    1. That you can go and work unsupervised and come back in a week with something good. (This is important in all jobs, but even more so in remote jobs.)
                                                                    2. That you can learn new technologies quickly.

                                                                    Then it matters much less if you know the language at hand (for good companies).

                                                                    You ought to be able to explain both of these decently in cover letter/resume, with examples etc.. (Long version, not specifically targeted to remote work: https://codewithoutrules.com/2018/01/23/job-with-technology-you-dont-know/).

                                                                    1. 1

                                                                      Then it matters much less if you know the language at hand (for good companies).

                                                                      This certainly should be true. It has definitely been true when I have hired people. However, I rarely see this attitude in job ads.

                                                                      1. 1

                                                                        People who write job ads aren’t usually very thoughtful about what they write. It’s just rote regurgitating of the standard format for job posting. (Lynne Tye is person who is trying to improve this from company’s side - see my interview with her - https://codewithoutrules.com/2017/12/01/interview-lynne-tye/ - and her job site - https://www.keyvalues.com/).

                                                                        If you pitch yourself in way that actually meets their needs, you can get the job regardless, because they’re like “oh right we do need that” even if they can’t consciously articulate it.

                                                                    1. 10

                                                                      Meh, I find this line of argument unconvincing… certainly using a specific toolset, could serve as a good basis for experience. Would you hire someone who has only done web development (and maybe has some experience with algorithms) to maintain a legacy COBOL system, optimized and written exclusively for some 40 y/o mainframe? It might not be a common example, but is is a kind of ad absurdum refutation in my eyes of the generality that the author makes. A more everyday example would be if you need to write some efficient system critical component on, let’s say a unix system, it’s certainly better to someone who has read alot about unix, has already wirtten utilities, knows the system calls and the advantages and disadvantages of libraries. Writing a physical simulation? I would guess that a stable background in mathematics, computational science and small hardware optimisations (eg. ++i vs i++) would come in more in handy than knowing how to position images on a website. And to not insult web developers, they have a tremendous advantage agains all the previous examples, and if one is already making the economic argument (think about the jobs!), speed and efficiency certainly seem important.

                                                                      All in all, one might not be ones tool, but one has ones experience, expertise and is probably more fit for some tasks than others, even if it’s only because of ones interests.

                                                                      (and the editor question seems to be quite perpendicular to this issue. This is a tool, but you can prefer one over another without making this an issue about identity. You just might be more used or find it more comfortable to write dd vs C-a C-k. Seriously levating this to the level of identity shows nothing more than a personal “shallowness”)

                                                                      1. 2

                                                                        I’ve worked in multimedia CD-ROMs. Then websites. Then software for airlines, with a lot of distributed systems stuff. Then just distributed systems. And now I’m doing image processing for gene sequencing, and dredging up memories of math classes I haven’t used in 18+ years.

                                                                        I’ve written production code in 6 different programming languages along the way.

                                                                        It is easier to stick to things you know, yes, but you don’t have to if you don’t want to.

                                                                        1. 1

                                                                          If you don’t mind me asking how’d you get into writing software for airlines?

                                                                          1. 3

                                                                            Got a job at ITA Software, which built the flight search engine powering many (a this point most?) airline websites, Orbitz, and these days Google Flights. We also built an airline reservation system, which was launched and then canceled by Google a few years after they bought ITA.

                                                                            There’s a still a whole team at Google working on this.

                                                                            Other companies are the big GDSes: Sabre, Amadeus, etc..

                                                                      1. 5

                                                                        I don’t believe I can disagree more. Tools matter, because some tools are better than others on some axis or axes. ‘Tools don’t really matter’ is the only argument one can make when one can’t argue ‘my tools are better.’ I don’t think any particular tool is better on all axes, but certainly some aren’t the best on any axis (e.g. pico).

                                                                        And I don’t think it’s inappropriate for someone who recognises a tool’s actual excellence in a world which incorrectly fails to do so to make that recognition part of his identity. It’s part of how an oppressed minority perpetuates its existence.

                                                                        1. 7

                                                                          This is a good point, but it’s also an argument against strongly identifying with your tools. If tomorrow you encounter a new tool that does something better than your current tool, it should be as easy as possible for you to abandon your current tools and take up the new ones, and that’s harder to do if being a user of a particular tool is part of your self-identity.

                                                                          1. 3

                                                                            “Oppression” seems like an overly strong word here, maybe…

                                                                            1. 1

                                                                              If you’ve ever been an emacs-user on a team of vim-users, you’d know what I mean. Or a Linux-user on a team of Mac-users …

                                                                              No doubt the other way ’round is the same, too …