Threads for srbaker

    1. 6

      I see you’re into Coffee? I see the Wacaco sticker.

      https://www.home-barista.com/ is the lobste.rs for Coffee.

      PS: You might already know about it, but others here might not :-)

      1. 3

        Yes I love coffee and everything about home made espresso.

        https://www.home-barista.com/ is the lobste.rs for Coffee.

        Wow thanks for sharing I did not know!

        1. 1

          I didn’t, and it’s way off-topic for here, but maybe someone in this thread knows:

          I have been looking for bean-to-cup filter machine that has a burr grinder and drips into an insulated (not heated) jug. So far, I have found precisely one such machine to exist, it doesn’t ship outside the USA, and reviews indicate it often breaks after 6 months. Has anyone heard of such a thing being mass produced? Or a kickstarter or similar for one.

        2. 3

          What type of keyboard is it?

          1. 5

            Looks like NuPhy.

            1. 2

              Yep! Great keyboard!

              1. 2

                Looks nice indeed! I’m going to pick one up and give it a try.

          2. 3

            How do you get the windows to organize that way, with the margin between them? Is that a Rectangle config I’m unaware of?

            1. 3

              Is that a Rectangle config

              Yep, that’s correct. You can do it thru UI or you can set it thru JSON. Here are my settings -> https://git.0x7f.dev/andreicek/dotfiles/src/branch/master/rectangle/RectangleConfig.json

              1. 3

                Thanks! This changes everything for me. :D

                1. 1

                  Same! I’ve been wanting to do this lately. I didn’t know you could do it with Rectangle itself and thought I’d have to do it with Hammerspoon.

          1. 4

            I loved everything about this: the personal introspection and interrogation of the author’s own biases and preferences, and the fairly well balanced look at both sides.

            Personally, I prefer working in dynamic languages. It’s a personal preference. And that preference is reinforced every time one of the type supremacists tells me “static language X will ensure you never encounter problem Y” where problem Y is something I’ve either never experienced, or on the rare occasions I’d seen it, it was better blamed on some other problem that wouldn’t have been solved by switching languages.

            That said, I’m not likely to reject a static language because it’s a static language. It’s just not that high on my priority list. I can’t think of a situation where I’d ever reach for a static language myself, but I also can’t think of a situation where I would try to convince someone to use a dynamic language over a static language for the same job on that characteristic alone. And in some cases, I’d argue in favour of a static language.

            iOS is a perfect example of this, in my experience. I strongly prefer Objective-C to Swift. But I wouldn’t try to tell someone they should use Objective-C instead because it’s better. They’re different, and it depends on what your goals are. (If your goal is “has static types” then you’ve misunderstood the question entirely.) If I were solving the same problem in Objective-C and Swift, my designs would look wildly different, but they’d still have test suites of the same size, the problem would be solved in both cases.

            I think the problems that people talk about come from people trying to do “dynamic design in a static language” or “static design in a dynamic language.” That’s a recipe for pain.

            I am really glad to have read this, and to be able to share it with others in the future.

            1. 3

              This reads to me like “I don’t like markdown because it promises not to do a bunch of things it was deliberately design to not do that I would like to be able to do.” It’s like saying “I hate Toyotas because they can’t fly.”

              I quite like Markdown: because all I want are headers, paragraphs, and very light styling. Which is exactly what it was designed for, and handles very well.

              1. 2

                Yes, that’s the impression I got as well.

                Three out of four of my last F/T paid roles were as a tech writer. I encountered various tools, most horrible, partly because of the “docs as code” movement in FOSS which I personally dislike. I used Markdown a little and AsciiDoc rather more. (Never touched RST.)

                But now I’m a journalist again, and Markdown has come to the fore as a really easy, quick, widely-understood format for writing for the Web. It does the core stuff I want, very easily, and the stuff that most of its critics kvetch about is stuff I don’t want and for which there are better tools.

                For instance AsciiDoc is about as easy but can do tons more. If you want to write docs, Markdown is probably too simple. If it doesn’t do what you need, then use something that does.

                I would not recommend MD for docs. I know lots of people are using it for stuff like that, and IMHO it’s a mistake. Anyone using MD and encountering friction or finding it inadequate is using the wrong tool and that is not MD’s fault.

              1. 6

                I nearly entirely agree with this article. I’ve been feeling the same for a while. I first gave up a lot of my Free Software principles in 2006 when I spent two days trying to get a second monitor working (and failing) on Ubuntu. I ordered a G4 Mac Mini.

                The things I loved then about the Mac are the things I’m looking for in a system. A focus on usability across apps: drag and drop should Just Work. The keyboard shortcuts for operations that are shared across applications (copy, paste, cursor movement, etc) should be the same in every application. When an OS update is released, I shouldn’t have to wonder what’s been broken, or change more than a few of my workflows. When i want an application, I want there to be a high quality one that exists.

                On the Mac, this used to be true. Copy is always Cmd-C. Quit is always Cmd-Q. Emacs/readline keybindings in every text field. At least until Snow Leo, I could grab the latest OS on day one and not miss one minute of productivity more than the time it took to run the installer. When I wanted my computer to do something new, there were many great applications, highly polished, and available at reasonable prices. And none of my previous habits (emacs, and heavy bash usage) suffered for it: emacs keybindings always worked (thanks to the Cmd key), and the terminal was a fairly good one (and now we have iTerm2!)

                But these days, most of the apps we have to use to interact with the world aren’t native Mac apps, and so the keybindings are a bit wonky. The applications I have to spend most of my days in (Slack and Zoom, primarily, but others too) are the worst offenders. And to make matters worse, Apple took the one respite we had from this shitshow: native Cocoa applications, and made them as bad (or worse in some ways) with SwiftUI, Combine, and whatever other flavour of the week they’re peddling.

                I get a more cohesive desktop experience on GNOME or KDE than I do on a Mac today. That says a lot about how great GNOME and KDE have become, sure. But it also shows how far usability on the Mac has fallen. Every time Apple rewrites one of their apps (Music is the worst offender) in one of these new “cross platform” frameworks, it becomes unusable.

                I have even more thoughts on the “it just works” and “you are rewarded for staying in the Apple ecosystem” ideas because the former isn’t true, and the latter has turned to punishment. :( I get more reliability syncing my Photos to Nextcloud than I ever got out of iCloud Photos.

                I could say more, maybe I should write my own blog. But I don’t think I’m saying anything anyone else isn’t, so it feels like a waste. I’m glad I’m not alone, though.

                1. 16

                  I like the list as a whole but disagree that Technical Debt needs to be retired.

                  My particular industry is full of code that doesn’t work well, is not easily debugged, and is not easily extended. And it is often requested to tape over issues in bad code instead of doing a rewrite of the egregiously bad parts.

                  Technical Debt is a great way to describe to product owners that this particular fix might be faster than a rewrite, but over the course of many fixes, using the bad code will be more costly over fixing the bad code. Incurring debt for a quick fix is a trade off. Many times it is the correct trade off, but the term “Technical Debt” describes the trade off well.

                  1. 17

                    Something I only recently came to realize about the term. When used outside of engineering circles, which is increasingly common, folks from the business side of the company hear it differently than engineers do. Engineers often mean it as “quick and dirty stuff we never got time to fix” or “stuff that used to be OK but has dependency rot.”

                    What the business side hears is “bad decisions tech people made that they want me to pay for”.

                    So I’ve definitely moved away from using that term.

                    1. 5

                      How do you frame the problem instead?

                      It seems likely that this isn’t the best-possible metaphor, but I’m also a little leery of framing it like in-group jargon that is accidentally escaping.

                      Technical debt has always struck me as a bald (and maybe even a little condescending?) attempt to frame this cluster of problems in terms the business side can (hopefully) grok.

                      Presumably the business people can understand the need to pivot product, fire an employee, or kill a project when they can’t get traction? But they can’t grok that tech decisions are just as prone to fundamental flaws (that usually weren’t obvious when they were made) or to age poorly as conditions change?

                      In product, talent, and tech–the time always comes to take stock of which way the wind is blowing and do what you can to put it at your back. If they don’t get this, it sounds like they’re expecting magic instead of a blob of tactical and strategic decisions made over time?

                    2. 9

                      In financial business, debt is a useful tool, deliberately taken on for a variety of reasons. In some cases, you can afford to pay it off at any time, but you choose not to because the debt isn’t necessarily a bad thing.

                      What bugs me about “technical debt” is I’m pretty sure the original meaning was similar to that, yet a lot of times it is just used to describe bad code, even when that bad code isn’t actually buying you anything.

                      1. 3

                        The quote from the article:

                        Previously something very specific used in the context of financial technology development. Now means whatever anybody needs it to mean if they want their product owner to let them do some hobbyist programming on their line-of-business software, or else. Can definitely be retired.

                        Weird take, as if from the leeriest of PMs though I know the author is not.

                        I honestly cannot understand how anyone who has worked in industry on legacy codebases could view concerns about improving code maintainability, reducing bugs, and generally making code faster to work as “hobbyist programming.” In my experience the types of things generally classified as “technical debt” are the high-order bit in improving all the things PMs generally complain about.

                        1. 7

                          The point is that many programmers call something “technical debt” when it’s not really: they’re waving hands and making excuses to do something fun.

                          I very recently heard “This is written in Objective-C, so it’s technical debt. We should re-write it in Swift.” The code in question had low churn, great test coverage, and few defects. It was probably the best of the entire project.

                          1. 5

                            The author’s position is like saying, “Let’s retire the word ‘sick’. It now means whatever someone wants it to mean when they need a free day off work.”

                            I mean, everything legitimate can be, and sometimes is, abused. Indeed, the excuse only has force because of the underlying reality.

                            In my own experience the phenomenon of PM’s, or programmers for that matter, avoiding technical debt when it needs to be addressed is far more common than the phenomenon of programmer’s abusing the idea to do whatever they want.

                      1. 4

                        I don’t have anything specific to say about this release.

                        But: darktable is FOSS at its best. darktable is a best-in-class tool for the job, and frankly its underrated. I love everything they’re doing, and I can’t wait to see more of it, and more projects like it.

                        Thanks for sharing!

                        1. 2

                          I’m curious what about it you like so much. I had hoped to move to Marketable as a replacement to Apple Photos, but I found it both very unreliable and made tasks I wanted to do more difficult than Apple’s alternative.

                          The main feature I’m looking for is something that can help me manage a large library oh photos (which I found Marketable fell over on almost immediately, even when just trying dozens of photos), and provide simple editing.

                          1. 2

                            I believe your autocorrect replaced “Darktable” with “Marketable”…

                            1. 2

                              The Darktable UI can actually be pretty efficient. It’s pretty clean and consistent, but it certainly isn’t easy to just pick up and start editing. It has improved on that, but to really make the most of it you will need to dig into the documentation. It uses a lot of unfamiliar terminology which can be overwhelming at first but once you get a hang of it you realise it’s not actually all the complicated (for what it’s doing). I’m not trying to make any excuses for the UI and I can totally understand why people might just feel it’s not worth it. For many people it probably isn’t.

                              But, it’s a very capable, and actually pretty well designed piece of software and you can get some great results out of it.

                              Edit: This specifically is what made it click for me (understanding the ‘scene-referred workflow’):

                              https://docs.darktable.org/usermanual/4.0/en/overview/workflow/process/

                              Going through that page will take you a long way, and from there you can start exploring different modules. But don’t try to take it in all at once (clicking around and enabling all kinds of modules at random).

                              1. 1

                                For me, I love that I can do so much of the retouching in RAW. It’s been a long time since I used Lightroom, but I couldn’t do spot healing or wavelet decompose skin retouching from RAW (which means I didn’t need to hop over to GIMP–especially since GIMP doesn’t have a good story for non-destructive editing).

                            1. 21

                              Heh. I hate this. And I’m the person who either invented this or popularised it. (Not sure which I did, but it was definitely one of the two. And I’m sorry.)

                              I find “should update count when …” is less good than “updates count when…”, especially because the popular frameworks these days use describe/it syntax (definitely my fault, and I’m sorry) and “describe AThing, it updates the count when …” reads better without should everywhere.

                              My test names answer the question “what does the software do when it’s working as described?” And “should” doesn’t answer that question: it doesn’t should do something, it does something.

                              1. 6

                                I should (ha!) elaborate. Basically, “should” is language that has overstayed its welcome. should was originally used in place of test because we were trying to get away from “test-centric language” where it caused confusion. So we made test runners that ran should_* instead of test_*. should is a better word than test when people are getting hung up on the word “test.”

                                But now we have better tools and language to write these things, and the word “test” doesn’t exist in many of the frameworks. Where there is no test there ought not be should. Where this is test, should is probably better. But we have better ways of writing this stuff in most languages now.

                                (I’m also less convinced that the word test is bad than I was in the early 2000s.)

                                1. 1

                                  I kinda miss 1.should eq 2 though, it’s nostalgic for me :)

                                  1. 7

                                    That was a nightmare to maintain, and only existed because of … a bad suggestion that I ran with. :D

                                    1. 3

                                      Still, it was (at least for me) a groundbreaking new way of thinking about tests and how to do them. When I was doing Rails back in the day, RSpec felt like it really expanded my mind. Cheers to you for having advanced software engineering in a meaningful way!

                              1. 16

                                This is great news! We don’t need to deal with splintering of these things. I love Matrix and Rocket.Chat, but I don’t want to have to install two clients.

                                1. 16

                                  Missed a trick by not randomly only loading greyed out boxes half the time requiring a refresh.

                                  I’d love everything about this if it wasn’t so spot on.

                                  1. 1

                                    Came to say this… greyed out boxes, so hot right now!

                                  1. 1

                                    I’m also interested in this idea of resilient computing. A lot of vintage machines are still up and running, the vintage computing and arcade restoration communities have been keeping them going for decades (and have pretty good intuitions about who built more or less robust technology). I think a more interesting and unexplored domain is designing for continuous operation.

                                    The best example I’ve come up with is something like the Voyager Spacecraft which has been in continuous operation for the last 44 years.

                                    As a strawman proposal imagine a computer with the following specs:

                                    • 100mhz CPU
                                    • 1 Gb of RAM
                                    • 250 Gb of storage

                                    If we target 50 years of continuous operation we’ll exceed the operating lifetimes of the RAM and CPU silicon (but honestly we’ll probably have power supply failures long before that). Anyway I think this is a very Long Now Foundation like question, but in the case of computing it’s hard to even get our design specs out to the 100 year mark.

                                    1. 4

                                      If we target 50 years of continuous operation we’ll exceed the operating lifetimes of the RAM and CPU silicon (but honestly we’ll probably have power supply failures long before that). Anyway I think this is a very Long Now Foundation like question, but in the case of computing it’s hard to even get our design specs out to the 100 year mark.

                                      I think we’re (as technologists) just really insecure about how ephemeral our field is, but most things aren’t permament. What’s wrong with being fleeting?

                                      In Japan, they solved the ship of thesus - they just tear down an old shrine and build a new one in its place. I don’t see what’s wrong with things changing and evolving over time - that’s just nature, and something the lasts a long time is an abberation.

                                      1. 2

                                        I don’t think there’s anything wrong with technology being ephemeral! But i think that’s the status quo, and so thinking about the alternative is interesting.

                                        I think it’s interesting to imagine what a computer designed to run for 100 years would look like, to consider what parts would fail first and what tools we have to work around those failures.

                                        1. 1

                                          In Japan, they solved the ship of thesus - they just tear down an old shrine and build a new one in its place. I don’t see what’s wrong with things changing and evolving over time - that’s just nature, and something the lasts a long time is an abberation.

                                          Usually I see the refrain that “bridges last for decades so why doesn’t software”, but that belies the reality that bridges are one of the few things that humans build that need to last that long due to the sheer capital cost in building them. Even then, bridges (like anything else) need maintenance. Everything else we build, from bicycles to combustion engines to single-family homes, changes as humans and human society does.

                                          1. 1

                                            but that belies the reality that bridges are one of the few things that humans build that need to last that long due to the sheer capital cost in building them.

                                            This is an interesting point, that I would have agreed with before reading some public documents on a few relatively simple IT projects recently. And I’ve seen similar public documents on some road construction contracts, including small bridges (but that have high weight limits for lumber movement.) Software projects aren’t as cheap as we think they are, unfortunately. :(

                                            The up front costs on these relatively simple software projects makes the bridges look cheap. And the software projects don’t last a decade before they’re replaced or overhauled.

                                      1. 8

                                        This is an awfully long post to say “I don’t understand OOP, and I claim to hate it based on this misunderstanding.”

                                        1. 16

                                          There’s a lot of good stuff in here that we all think everyone knows and we say to each other in the pub but we don’t really say out loud to the people that need to hear it.

                                          The main one that comes to mind is about mobility. They said something like “if I get fired I’ll have a new job in two weeks.” The tech folks that don’t know this is true need to learn it. More importantly: the people who manage tech people need to learn it.

                                          1. 22

                                            if I get fired I’ll have a new job in two weeks.

                                            This has never been true for me. Job hunting has always been a relentless slog.

                                            1. 12

                                              Imma guess it depends on where you are. Silicon Valley, Seattle, NYC, London, you can basically put your desk stuff in a box, and throw it out a window and have it land in another tech company’s lobby.

                                              Other places, not so much.

                                              1. 9

                                                I agree living in a tech hub makes finding a job way easier, but I jump to temper the hyperbole just a bit. I know that I personally felt a lot of self-hatred when I tried to change jobs and it took months of applications and references and interviews to actually get one, even living in a tech hub.

                                                1. 6

                                                  Technology stacks don’t really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it’s not going to be the same as webdev or embedded.

                                                  It depends on what you do. The author is a database specialist, so of course they’re going to claim that SQL is the ultimate language and that jobs are plentiful. I’m an SRE, so my career path requires me to pick specific backend-ready languages to learn. I have several great memories of failed interviews because I didn’t have precisely the right tools under the belt:

                                                  • I worked on a Free Software library in Python along with other folks. They invited me to interview at their employer. Their employer offered me a position writing Lua for production backends. To this day, I still think that this was a bait-and-switch.
                                                  • I interviewed at a local startup that was personally significant in my life. I had known that it wasn’t a good fit. Their champion had just quit and left behind a frontend written with the trendiest JS libraries, locking their main product into a rigid unmaintainable monolith. I didn’t know the exact combination of five libraries that they had used.
                                                  • I interviewed at a multinational group for a position handling Kubernetes. I gathered that they had their own in-house monitoring instead of Prometheus, in-house authentication, etc. They also had a clothing line, and I’m still not sure whether I was turned down because I didn’t already know their in-house tools or because I wasn’t wearing their clothes.
                                                  1. 3

                                                    They also had a clothing line, and I’m still not sure whether I was turned down because I didn’t already know their in-house tools or because I wasn’t wearing their clothes.

                                                    Seems like a blessing in disguise if it was the clothes.

                                                  2. 3

                                                    I have this problem and I’m in a tech hub. Most of my coworkers and technical friends are in different countries I can’t legally work in, so I rarely get interviews through networking. Interviewing is also not smooth sailing afterwards.

                                                  3. 5

                                                    This has never been true for me. Job hunting has always been a relentless slog.

                                                    Same here, I also live in a city with many startups, but companies I actually want to work for, which do things I think are worthwhile, are very rare.

                                                  4. 7

                                                    There’s a lot of good stuff in here that we all think everyone knows and we say to each other in the pub but we don’t really say out loud to the people that need to hear it.

                                                    Interesting that you say that in the context of modern IT. It has been so with many things since ancient time.

                                                    https://en.wikipedia.org/wiki/In_vino_veritas

                                                    Perhaps the traditional after-work Friday beer plays a more important role in one’s career than most people think. Wisdom is valuable and not available ons course you can sign up to.

                                                    1. 1

                                                      Wisdom is valuable and not available ons course you can sign up to.

                                                      Which is ironic given wisdom is often what they’re being sold as providing.

                                                    2. 5

                                                      The main one that comes to mind is about mobility. They said something like “if I get fired I’ll have a new job in two weeks.” The tech folks that don’t know this is true need to learn it. More importantly: the people who manage tech people need to learn it.

                                                      Retention is a big problem. It can take up to a year to ramp up even a senior person to be fully productive on a complicated legacy code base. Take care of your employees and make sure they are paid a fair wage and not under the pressure cooker of bad management who thinks yelling fixes problems.

                                                      1. 2

                                                        That’s probably why the OP says their salary went up 50% while their responsibilities reduced by 50%. Onboarding.

                                                    1. 6

                                                      <rant>

                                                      Next to me on my desk I have a very good book, “Making and Breaking the Grid”, which is about graphic design.

                                                      I am not very good at graphics design, but I want to be better, so over the years I’ve collected a dozen or two books on it.

                                                      These books are classics. I can pick them up 50 years from now and get information on things like the grid, typography, A/B testing, and so forth. They contain no tech.

                                                      By the same token, I’ve got easily 100x that on technology to actually implement the concepts in these books. These books are good for about a year or three. Every so often you have to either toss out what you have or put them in cold storage. (Anybody looking for a good AJAX book?)

                                                      The problems don’t change on these crazy fast cycles. The technology does, however. So as a professional you have to ask yourself: is your job to master solving problems and then choosing and applying tech to do so, or is your job mastering tech and then taking whatever problem you’re given and throwing that new tech at it.

                                                      This is not an anti-tech/Luddite argument. If the cool thing you’re using can solve the problem better, use it. This is an argument about what things drive what other things. I’m willing to bet that there are a lot of folks using things like CSS Grid who’ve never read about or used grids “in the wild”. Some of these folks might even be UI/UX folks. For those folks, how would they ever be able to tell whether a new tech was actually useful for something they needed, or just something new and flashy? We’ve gotten something seriously backwards in our industry, and it’s not just limited to CSS and graphics. </rant>

                                                      1. 3

                                                        Indeed! I wish I had a better sense of what factor(s) drives this too. Is it people trying to get promoted and optimizing for “new shiny tools” to say they fixed a problem (without actually fixing the root of the issue)? Are we afraid of going “deep” into the problems and so we just build superficial wrappers / abstractions that make sense to us but no one else?

                                                        1. 4

                                                          (unsubstantiated opinion follows)

                                                          I love photography. I’m not that great at it, but I’ve been shooting pictures for decades and I feel like I’m getting better.

                                                          I don’t read photography things online. Why? Because, in my mind, the business of making and buying photography gear is not related at all to the business of actually shooting good pictures. Don’t get me wrong: I’m a huge photography gearhead and have serious nerd envy about some of the hi-res/low-light/HDR gear I’m seeing. It’s just that the gear doesn’t make the picture. Sure, it can help take a good idea and turn it into an excellent picture, but it’s the idea and the expertise to translate it that drives whatever gear you might or might not need, not the other way around. Mozart would kick ass on a ukulele. No matter how hard you bang on that $100K piano, you’re not going to sound like Mozart.

                                                          People buy things based on the benefits they’re promised. When these things get complex, the person buying is never sure if their average/poor results are a result of poor gear or something else. This leaves them open to buying even more cool gear next year. When you don’t have a feedback cycle, the feedback cycles becomes something akin to “what the other cool kids are doing”. This is why fashion designers pay models to be seen in their outfits. We are herd creatures. If you can’t do a good job, you can at least hang with some really awesome people playing with some seriously cool stuff while you blame your poor results on something else.

                                                          1. 3

                                                            That’s true there is certainly a ‘mimesis’ component to all of this (both individually and organizationally).

                                                            I have seen what you’re describing re: photography / music in a lot of hobbies. Mastering the fundamentals is difficult and takes time, so people probably figure why not spend more money on more powerful gear to on one level emulate the masters, and on another feel like they’re getting more immediate rewards.

                                                            I suppose the same general train of thought applies here in how we manage software abstractions, complexity, etc.

                                                        2. 2

                                                          This is related to something I realized recently while looking for a CAD package. I am very familiar with FreeCAD, and it’s great. But the interface is clunky, and I have a large project I wanted to undertake so I thought I’d look at the alternatives: AutoCAD, Archicad, Rhino, and a few others. I was shocked, shocked I tell you, to learn that FreeCAD is actually the best of the bunch. Easiest to use, complete feature set, easily extended.

                                                          I compared this thought to when I met some architects a couple years back. I noticed pretty quickly that these architects weren’t architects at all: they were AutoCAD users. They didn’t learn architecture, they learned AutoCAD. Some learned Archicad.

                                                          The same is true in programming: we have Java Programmers, where we used to have Software Developers (many are the latter, still, but it’s not typical.)

                                                          I suspect we’re seeing the same thing in “web design” and so on.

                                                          1. 3

                                                            I used to do Agile Tech coaching, ie, I knew both how to code and how to run good software projects.

                                                            Time and time again, I’d see somebody ask another coach a question, like “How do we split User Stories?”

                                                            The answer would be “Well, you right-click on the link in the kanban column, then choose ….”

                                                            They were explaining how to split User Stories, that is, the physical process of using the tool. But they weren’t actually explaining how to do it regardless of the tool. The building were full of folks like that. We were using traditional classroom methods to teach people how to operate tools, not how to actually do the work.

                                                            I stopped doing that job. It was too depressing. A lot of activity and work, but progress was actually going backwards.

                                                            1. 2

                                                              I just got back into doing coaching, and I’m finding the same things now that I did almost a decade ago. It’s like we’ve learned nothing.

                                                              1. 2

                                                                I feel like some really great coders and mentors came up with some things that worked, managed to generalize them so they continued to work (which usually doesn’t happen), but had no idea why they worked.

                                                                Nothing wrong with that, at least until you get thrown a lot of edge cases and the field fills up with people who want to look smart and publish. Then, this simple idea grows into an entire industry. It becomes a monster, a monster that’s not actually about making stuff people want. (It’s about doing coaching that people like. Not the same thing!)

                                                                I also did my share of publishing, figuring out (I think) why things work. And know what? It doesn’t make a difference. It’s still about “meeting people where they are” and playing “tell me what you want and I’ll tell you that’s what you need” Note: it’s not that it’s crooked, it’s that trying to help people without a good theoretical foundation can never scale past a few clients and a couple of years. It grows into a marketing monster and stagnates. Nothing is ever going to change there, and still those initial ideas have a lot of merit. You just can’t build on them without destroying the thing you’re trying to promote.

                                                                I hope never to go back. I think I’d rather sweep streets. My life’s missing is to make developers happer and more productive. I’m sticking to that :)

                                                                1. 1

                                                                  I feel a lot of this.

                                                                  My life’s missing is to make developers happer and more productive. I’m sticking to that :)

                                                                  My personal approach to coaching is basically this. I’m fortunate to be in a situation where I’m able to do it this way, though. And I don’t know why I can, so I can’t replicated it. :D

                                                        1. 21

                                                          Most of the things he praises — compact lambda syntax, Enumerable replacing “for” loops, everything is an object, MVC — came directly from Smalltalk-80. Often with exactly the same syntax. I think a lot of the genius of Ruby was to mold Smalltalk into a form that was more familiar looking and worked well as a scripting language. (ST-80 had no notion of a source file, nor of unbound functions nor top-level code not part of an object.)

                                                          1. 1

                                                            When I was first introduced to Ruby in … 1998 I think, I was told “It’s like Perl, but OO.” And as a Smalltalk enthusiast, I thought “Well, I don’t want OO Perl. I want Smalltalk.” And passed without even looking.

                                                            The next person who introduced me to Ruby in, 2001 I think, told me “It’s basically a Smalltalk that knows how to interact with the rest of the world.” I looked, and was immediately hooked.

                                                            I consider Smalltalk and Lisp to be perfect*, and everything else is a compromise. Ruby provides what I consider to be the fewest compromises, while providing interoperability with the rest of the world. It’s situationally-perfect, I suppose.

                                                            * I often say “Smalltalk-80 is so named to commemorate the year in which it was perfected. Lisp doesn’t have a year modifier because it came out perfect.”

                                                            1. 1

                                                              What do you think of Crystal?

                                                              1. 2

                                                                I don’t dislike it. I think it’s a great compromise for people who care about the things it offers, but it doesn’t offer anything I care about.

                                                          1. 6

                                                            Throwing this out there - the distance you created can be reclaimed. The maintainers today would welcome fresh contributions!

                                                            I also agree that Chelimsky was an incredible steward, maintainer and contributor. He set the course that made RSpec what it is today, and it’s dang good.

                                                            It’s worth calling out that Myron Marsten, Jon Rowe, Penelope Phippen carried that forward into being rock solid, reliable, and dependable.

                                                            What I would like to see going forward is some kind of bridge into property based testing. I don’t have a complete vision for what that might look like, but it would open up a world of possibility.

                                                            1. 8

                                                              Oh, I’m not sure I care to reclaim any distance. It’s a mostly good memory at this point. I have regrets, which I think I shared effectively, but I couldn’t be more proud of where it’s at today. And the current maintainers are fantastic.

                                                              I tried picking up some tickets a few years back, and it didn’t feel like home anymore.

                                                              I guess I like what they’ve done with the place, but all of my furniture is gone, so it doesn’t feel like home anymore. Maybe the future holds something different, though.

                                                            1. 23

                                                              The author even points out that XP only says we should pair on production code. If you’re pairing 8 hours (or more!) per day, you’re being overworked and exploited, or you aren’t doing your whole job.

                                                              I have seen very few gigs where there isn’t at least an hour a day of email and other administrative tasks to do. Then there’s a lunch break, and bathroom breaks, trying out a new thing, reading some documentation, answering questions from colleagues.

                                                              If you’re pairing more than 4-6. hours in a given day, you aren’t doing your job as a software developer. You’re being exploited as a code typist.

                                                              Pivotal is well known for this kind of thing. They strategically schedule their “famous breakfast” to get people to show up earlier. And also strategically order not-quite-enough food so people are encouraged to show up early, so they get some.

                                                              When you “require” eight hours of pairing per day, you’re getting all of the administrative time “for free,” or you’re preventing your people from doing their whole job. It’s toxic, and the only thing I don’t understand is why some people are surprised at the burnout.

                                                              1. 49

                                                                As the saying goes:

                                                                The first rule of distributing systems is don’t, if you can avoid it.

                                                                What’s been amazing to me has been the amount of time and effort spent on this technique outside of the small fraction of places it makes sense, all while it is trivially obvious for anybody who stops and thinks for teo minutes what the problems are gonna be.

                                                                The conference-industrial complex sold snake oil and everybody just lapped it up. Such is the quality of “engineering” in software.

                                                                1. 29

                                                                  And worse, the snake oil often claims to cure a disease most people don’t have in the first place: the need to scale up dramatically on extremely short notice.

                                                                  1. 33

                                                                    I read a joke somewhere (I cannot remember where): “kubernetes. An ancient Greek word for more containers than customers.”

                                                                    1. 4

                                                                      I believe @srbaker coined that phrase.

                                                                      1. 3

                                                                        Corey from Screaming in the Cloud (https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/) has a variant of this (if I’m remembering well):

                                                                        Kubernetes, the Greek god of spending money in the cloud

                                                                        1. 2

                                                                          Boss wants to market horizontally scaling when vertical would be 10x cheaper :)

                                                                    1. 3

                                                                      Hopefully replacing the neutral inhibitor switch on my tractor.

                                                                      Also working on a native Smalltalk OS for RPi4.

                                                                      1. 2

                                                                        I read that as “neural inhibitor.” That would have been one hell of a tractor!

                                                                        Do you have code up anywhere for the OS project, it sounds really interesting.

                                                                      1. 1

                                                                        I love that this has been done. I wonder why it’s taken so long; it seems obvious. :/

                                                                        1. 3

                                                                          Came here looking for a modern application to play my MOD files.