Duration 37:38
16+
Play
Video

RailsConf 2019 - The Selfish Programmer by Justin Searls

Justin Searls
Co-Founder at Test Double
  • Video
  • Table of contents
  • Video
RailsConf 2019
May 1, 2019, Minneapolis, USA
RailsConf 2019
Request Q&A
Video
RailsConf 2019 - The Selfish Programmer by Justin Searls
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
6.95 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speaker

Justin Searls
Co-Founder at Test Double

I co-founded a remote agency called Test Double. Our developer consultants join the software teams of our clients to (a) provide extra hands to get things done and (b) help instill continuous improvement. Our developers are all highly-experienced technologists with a speciality in long-term sustainability of both code and humans, so we find ourselves helping teams get better at everything from testing to delivery process to paying down technical debt.

View the profile

About the talk

RailsConf 2019 - The Selfish Programmer by Justin Searls


Using Ruby at work is great… but sometimes it feels like a job!

This year, I rediscovered the joy of writing Ruby apps for nobody but myself—and you can, too! Solo development is a great way to learn skills, find inspiration, and distill what matters most about software.

Building a real app on your own can be overwhelming, but this talk will make it easier. From development to monitoring, you'll build a toolset you can maintain yourself. You'll learn a few "bad" practices that will make your life easier. You may even find that selfish coding will make you a better team member at work!


Share

Okay. So the title of this presentation is the selfish programmer exploration of what you can learn by writing software for yourself as opposed to on a team or part of a larger organization now shows that the three most important traits in a successful solo programmer or that they be antisocial egotistical and irresponsible and we're going to spend time today discussing all three about you may know me by this old picture that doesn't quite look like me or as Searles on Twitter and GitHub and I'm a self-professed expert and selfish programming I come from a company test double company are

double agents join client teams as additional developers to work alongside them and get things done while also searching for ways to help the whole team improve over time. Now I'm here today cuz I have a problem and that is that learning Japanese is really hard. I've been working on it for 15 years and I still have a long way to go but a couple years ago, I thought an application called wanikani and helps you memorize kanji in vocabulary. It uses a spaced repetition system or srs-2 time when you should review items to help you memorize them. So it'll challenge you to remember

something for a day and see if you can remember it for three days and if you can then maybe a week, but if you get one wrong, you'll just review it more soon. And as time goes on it might be a month before you see an item and then the app assumes that if you can remember something for 6 months, then you probably know it and it'll consider that one done and you can focus on the remaining eight thousand words. The interface of course is like a little flash card game. So you see the Japanese and then you provide a reading so it's tsunahiki in this case as well as it'll challenge you to

provide the English meaning word means tug-of-war and because I got it right the timer systems going to push it off to a later review day. So what I found was this application was awesome for teaching me how to recognize Japanese and understand it in English is very good for that. I can read a lot better now than I used to but for being able to produce Japanese words out of English ideas. It just wasn't very effective because it doesn't practice that muscle. So when I was talking to my conversation partner right often be tongue-tied trying to think of the right word, so I built an application

called comments, which is a companion after wanikani. It is literally the same thing except in Reverse. So you see an English prompt and then you use a Japanese keyboard to provide the word and you can get right or wrong that uses the same kind of timer system for helping you memorize how to produce the word. Additionally it was important to me to make it up Progressive web application so that it could survive just connects as well as it's a great way to practice the Kana flick keyboard that's popular in Japan. And most importantly kiss is all about learning building, Sami

taught me a lot about selfish programming. And so today I'd like to start talking about white can be good to be a little bit antisocial. So world 1 stage 1 the selfish programmer is unambitious and because it's easier to stay motivated when your goals are incremental and achievable when goals are too ambitious we run the risk of exhausting ourselves without accomplishing anything which might lead to us quitting and giving up cuz work work is different at work or after big they have lots of different parts. They have their own operations and those have their own parts and we can trust that

if somebody is working on this part of the Apple over here, we can safely focus in this area over here knowing that they've got our backs covered. But the problem with large apps is that our brains aren't big enough to fit them all if we try to quickly move from area to area the amount of context switching costs a sort of like memory paging do people tend overtime to specialize in large systems on one area. Even if they run the risk of kind of forgetting how to build an entire app all by themselves and just talking about this problem make me nostalgic for 2005 when I first started using Ruby

and rails cuz in my mind what Made ruby famous was that enable developers as individuals to make small useful apps without any help and because Ruby makes it easier to keep the whole app in your head at once. It's also great for moving more quickly through out of codebase. So all that is making me excited to create a new solo Ruby app for the first time in a few years. But even after several days of effort, I unfortunately only completed like one small part of this flashcard app that I wanted to build and it was useless by itself and it got me thinking about all the other

pieces that I'd have to build. It was really demotivating somehow over 14 years. I done learn how to make small things. I become too ambitious Sunday night. I don't do it and the one weekend rule is a liberating constraint cuz it's forced me to shrink down my dreams to something small enough that I can get done with the side effect of also fitting inside my brain since I'm able to work more quickly as I do. So I tried to imagine the tiniest useful thing I could make and I decided on the gym to tell me

whether my flash cards were ready for review or not in wanikani. So it called when Connie and when you run it, it'll tell you oh, you know, maybe you don't have flash cards and I'll come back in 11 hours. And when I do have flashcards, it'll print the Ural and I should go to go study really simple code. Of course. It just uses Netty HTTP and Jason and implements a single Methodist. I was like, hey, how many seconds till your next review? So it goes out to a URL parses the response if there's no error then, you know, it reads the information if I've got reviews available across the answer is

0 seconds. But otherwise, it'll do some math. And this was super simple. It was easy to test and it was easy to fit in my head and importantly it gave me experience working with wanikani is API. So this help solve one part of the larger application that I want to build it would make it easier for me to build that later. So excited for my next weekend project. I decided I wanted to take a bite of the apple and build the English to Japanese flash card game, but that was just too much to do at once cuz it involves complex game logic as well as a complicated user interface. I'd never finished

that in one weekend. So I carved off just a small piece just the game logic and now to solve the problem of how to make that you felt so I can enter 8, I just had to wrap it in a throwaway command line app. So that app looked like this and I spent several weeks. Just working on this side. I get an answer right and wrong and print it out. I realize that there were a lot of synonyms and so I had to handle that gracefully did things like persist my progress over time and set up all those timers. Because I knew this was a throwaway CLI. It was intentionally trivial. It was it's a while loop with

read line and a bunch of put statements and we strip away those bits what you're left with is actually interesting. I had code that like actually a crew could create Real review Q's could accurately like judge the responses that I was giving it and that could persist my progress. So that we can project was actually a huge success because it became the actual code that still runs the real web application today. Incremental accomplishment can be really motivating and that's why the selfish programmer is unambitious and works to shrink their dreams down until they're easy

to accomplish. All right. Let's talk antisocial stage to the selfish programmer is ungrateful of Open Source and understands that if dependencies are added carelessly. They may create an maintainable mess for themselves by lights in Vision applications, like pyramids at the top is our actual application code and below are all of our dependence. He's a really large applications until the marginal cost of adding just one more gym seems pretty low. But when you're solo you know that your time is limited and so if we had too many gems things like upgrades

and workarounds may eventually consume more time than we have to give me out. But arbitrarily limiting ourselves to just two or three gems is not much of a solution right because then we wouldn't be able to build very useful things until this is why I started to categorize my dependents how much I trust them and their maintainers to take care of stuff for me. For example, even though rails is very large and installs 41 other gems. I trust rails Gorda carefully curated those things and make it easy for me to stay up-to-date and so I can see with my junk file as head of two halves. They're

smaller gems maybe where I don't know the maintainer or they're not very well-maintained and if something goes wrong, I'm probably going to be on the hook for taking care of it and then there's the really popular gems. We're certainly my little tiny app isn't going to be the first one to discover a problem and somebody else is probably going to ride a patch for me and I worry less about those ones. Separately at work. I've been conditioned to never reinvent the wheel that is like write my own code. There's already other codes I could do it for me. But when you're solo you can choose to be

ungrateful and write some code even if there's a gem that claims to do the same thing examples, maybe a gem works, but it's such as the whole universe just for one feature and the gems usefulness isn't worth the maintenance cost of 28 additional gems. Another problem is when Jim is too hard to learn getting frustrated by a framework or a library is one of the top reasons people quit their solo projects and you know Reinventing the wheel might be bad, but outright quitting is certainly worse. Super example of specialization at work. I've never really been responsible for authentication features

before my solo app. I was by myself in somebody had to figure it out and in the past I've tried to use the popular gem device but I've failed miserably each time and understanding it and so I was afraid that if I tried again I get frustrated and I quit the whole project. So I started with a super basic password field installed bcrypt I use rails how secure password and it actually worked that gentle. Klein was all I needed for the first five months of the existence. And yes, I've been changing passwords and verifying emails and you know, if forgot password reset link and

yes, those custom features probably complex enough that I would have spent more time writing them than just learning to buy in the first place. And yes, I'll admit the generating custom tokens and saving them and emailing them and then handling a little click in the verification email is it all felt silly because I knew that device could do this for me, but I'm still proud that I did it by myself cuz I understand my implementation completely and probably finally gave me a safe place to practice something that I wasn't very comfortable with so now I don't feel so stupid. You can try to

solve every single problem that you face by Googling for gems to do it for you. But just because dependencies are easy to install. It doesn't mean that they're going to be easy to deal with later. So this is why the selfish programmer is ungrateful weather at work or solo if he's off to think critically about the trade-offs that we face for each dependency that we add. Alright antisocial stage 3 the selfish programmers ungenerous and doesn't worry too much about making code reusable be at work. I was trained to share as much as possible in order to be a good teammate

ever. I added some code I could have I could have put it to live with the future that I was writing but more often I put it in like in a model and then I invoked it for my future and this is fine, but eventually when teams work this way, it can really slow them down. For example, maybe a second future also add some code to that model and calls it a third teacher maybe reuse has a bit of code in the fourth feature reuses some more. And after this is one of these other callers needs to make a change to that shared code. You have to consider all the other things I

call it because it might blow them up in my break their behavior. When you have to check every single call site for any of your shared code. Additionally when you have these kind of like high traffic areas where they call each other and pretty quickly if we end up in this table hangover everything called everything and so making any change can be really precarious and difficult. So instead I prefer to soundproof my code and that means I put it in a set of shared places. I try to have the code live with the future

and I only extracted if it proves to be valuable later as a result. Most of my code is pretty isolated and I can safely and aggressively change refactor it and most of my models and things are just dumb value types that I passed in and out of those pictures. This impact how I divide responsibilities when coding, for example, this controller action does two things first in books get your code to perform a search and 2nd in Boca General utility code for the API responsibilities up to soundproof the future code and minimize the general utility code to the Future

specific code is only called one time, which means I can change it really aggressively I can be as messy as I needed to be but the general purpose code is kept really minimal because called in 7 different places and so it's much more work if I want to change it. Separately, I don't allow word the word model already being active record model to have a like much if any future logic in it. It's l i tree Trail subclasses as a DSL for configuring rails and not a place to put my own custom code because if I were to add just one method to my word. RV file, it would look small but it would

actually be at 312 method and that means the contract between it and people to call it is kind of murky. But if I create a separate class with just one purpose and one method it's going to have a clear contract with anyone who calls it. I've got evidence soundproofing code really works because for over 1 year, Simon started is actually like at the code base was just an example sentence search engine that was completely unrelated called sentence a and only later did I add, so I'm a red on top of the same models in database and it required zero changes the sentence a for them both to work and

best of all of a year later. I deleted sentence a and, none the wiser everything Dakota separated. Fort Worth code is often treated as a valuable asset and I give us this mindset of thinking that like reused will somehow make our teams go faster, but the more places that the more careful our changes have to be a programmer is ungenerous and not afraid to write a little extra code in order to gain the flexibility of changing it aggressively later. That's a little bit about why I can be nice to be antisocial when your programming by yourself. So now let's talk

about the virtues of being egotistical. the world 2 stage 1 the selfish programmer is delusional because sometimes it is necessary to believe that your coat is good enough to shift even when it's really bad. So this is the, Sami homepage, you'll see that you have progress here like XP and level in that sort of thing. And it's driven by this simple little API. It's a small response. But look at how many furries are does kind of convoluted at work. This code never would have passed a code review because once merged the team collectively owns that code so the you know, any problem becomes

the Kingdom Hall problem and this results in our teams generally having a higher bar for Quality up front, but if you never create a new Branch, then you don't need to worry about floor Quest reviews. so Because this is our solar project. I'm just pushing to master all the time. And I just try to keep it working. So the Celtics programmer is delusional because they choose to believe the features are ready as soon as they work and if we try to perfect that code in advance, we'd only be guessing as to what the ideal design and optimization should be instead of me. Push

this messy but working code we can take time and observe error reporting feedback and gradually improve that codes Behavior as we learn and do overtime. I find myself adding to this route and subtracting things and adding code but all the time resisting the temptation to optimize its performance instead. I waited some more and after a long time pass without changes I could be confident of the Futures Behavior was mostly correct. This code never tells us when it's done by just choose to believe that once code no longer needs to be changed. Then it must be right and that means

then we can turn our attention to how we might optimizer. Silver call this is a lot of queries and I needed some way to gather all that data without making so many trips to the database because if you were to think about this architectural 8, we have a lot of Ruby logic up top and it's great for prototyping. It's really easy to change but it's super slow. Right because it's calling postgres so many times. So I spent a few hours and Views and postgres is great at doing math and aggregation. So these people abuse do everything that Ruby was doing except faster.

So because that behavior is finished. It's okay that this is kind of ugly around harder to change a fact actually active record can talk to SQL views as if they were models just over right read only the truth and be safe and you can query it just like you would any other model in your system. So now for the payoff we're able to go from all of this code here just a single acting record model. It was backed by a sequel to you. So the Ruby is not responsible for much less and the code is all so much simpler than you can even look at the architecture look similar, right just a

little bit of Ruby calling to an admittedly kind of complex postgres query and predictably that route is now much faster than it was before I wake up. I recommend, you know, we start by shipping code as soon as we can make it work let those changes simmer until we've made it right and only then make it fast by pushing that code down to a you know, a faster layer. So pure pressure to write good code at work and try to make me a perfectionist over the years but this results in any future proofing behavior and optimization before I have any real database those decisions on so that's why the

selfish programmers a little bit delusional believing that messy code is good enough to put in front of users so that they don't waste time guessing how to perfect it. Next up egotistical stage to the selfish programmer is narcissistic because they ask only how an activity will benefit them before they decide whether to do it at work are large apps usually have lots of units and lots of tests of those units that call them and then is heard a response. The whole system and then verify it works dress

very different needs. Test for example, help build trust that are app is doing what it's supposed to do and we have lots of things past create a safety net so we can focus on one area without being sure that we're not breaking other things and third test can help express our intentions to our teammates into our future selves of what we're really trying to accomplish the barcode. What day is testing benefits have less value value on solo projects? Like you're the one determining the directions so you don't need to prove to anybody what you're doing. The app is probably small enough

that you can focus and move quickly. And when you're by yourself, there's probably more efficient ways to denote your intentions to yourself then writing a whole bunch of tests. So because of this I took a new approach to testing for, so I may just called and I do it for you now. So here's a Spanish recording of a full test run single test is going to win through a bunch of different parts of the application using browser testing before it looks a lot like that. Doing things like I doing some flash cards. searching

going to account settings change your name in password logout login be out probably works and I go ahead and push the master the downside though is that this test takes three whole minutes of my bill to run and I want to be able to push the master and go as fast as I can so I can go about my day. Citizens were a eye testing really shines first. It looks at only the most recent changes to the code and then it only runs the unit tests that like were affected by that change that and then finally the browser-based test dynamically adjust only cover the affected area. So

here's the same test run again after I make a change just the one feature is going to do some flash cards spelling feature time there. Go back from a search verify that's there and so on and so forth and of course, but the confidence is still high because they test focused on where they actually changed and most of all I got the bill down to just 20 seconds. And so I should confess. However that stands for average intelligence of enabled truth be told I actually didn't write any automated test for

Because I wouldn't have gotten a good return on my investment. Remember the primary remaining benefit. Was it telling me whether the app work but I intentionally designed the app to be really easy to manually check whether it was working by Pink focused and neuro testing comes to pay for itself right away, you know, yes you invest in writing them and running them and changing them but you know, you could run them locally you run them and see I may be your teammate makes changes and then residency, I been by the time that you've merged them into Master, you've probably gotten a payoff you

no more benefits than you've invested in good tests. But when you're so low that investment cost is similar, you still have to build and run and change them all but the value is mostly limited to running them locally and then once MCI and yeah, they might pay off eventually, but at least initially there's a little bit of a gap there. Is the most active use with developers do to deal with supper problems can be categorized as either trying to maximize mttf for mean time to failure that stuff that we do to prevent things from breaking or minimize mtpr the meantime to repair the

amount of time before we fix something when it does break. It's probably important for us as professionals to balance our skills between these two types of remediation. So personally I spent most of my career mostly focus on maximizing mttf. I rely on tests and compilers and Lynhurst to avoid production issues out right but by not writing how many time you've given me a great chance to improve my skills at monitoring servers and analyzing error parts and debugging problems. So why do people assume things like testing are always worthwhile just because somebody told

them to but when you're solo it's your time that you're investing. So you need to do more critical like this is why the selfish programmers narcissist it was only after deciding but like I was spending my time to benefit myself that I could do the math and then stop feeling guilty for the fact that I wasn't writing test for my own solar projects. egotistical stage 3 the selfish programmer is domineering because they're comfortable saying no to people a lot. Most people agree that great soccer requires a clear narrow Vision, but telling people no is

really hard when you're solo you're not just the only developer and the only tester you're the only product on her too and product owner is a really hard job at work product owners have to juggle the concerns of many different stakeholders marketing Finance security support not to mention the needs of the application of cell and product owner has to set priority which is going to make some people happy and frustrate others. So I decided early on I was always going to release comments on me for free. Cuz as of today we have about 2,300 users who've done millions of reviews. But as of today, I

still only has one customer me and I have zero other stakeholders. Does that makes it much easier for me to tell people no as product owner. I knew exactly the features that I wanted it first, but after lunch, I kind of ran out of good ideas. I just needed some inspiration. And so I started with Reddit wanikani has for him. It's got a whole bunch of post. Basically. This is me just farming ideas out of this community of how I can improve the application. So I give comments on my way from for free and I get free ideas back in return. And of course a lot

of Kamisama is only customer. I don't want to spend my personal time building it. But sometimes I get a message like this one it was from a color-blind person who said that the color coding of kanji and vocabulary was too subtle and resulted in an accident on the steaks, but I'm not colorblind. So I wasn't for that fixing. This would benefit me somehow so I looked closer at it for context vocabulary card asking for a multi character adjectives and hear the kanji card asking for a single character response saturate them and then overlay you can see how just visually

similar to be a few things are so I just looked closer and realized I'm already doing a lot of clients. I'd validation here. I'm checking for empty answers and alphanumeric answers phonetic answers to Khan ji questions. I realized I could fix this by just adding one more condition. So checking to make sure that the length is one if I'm asking for a single character and then updating this message. So now the app direct me and I can fax Payson to enter without the erroneous failure being reported. So even though that features

inspiration with somebody else's problem be improved validation has helped me many times to in fact most of my favorite features of the app where somebody else's idea solving somebody else's problem and I benefited from it too. And so, you know at work just shut up and blindly follow orders for the selfish programmer gets lots of practice being domineering because they must control their own priority and Direction. So yeah, it work it down to you but I found it teams that struggle over Direction together 10 to write better software.

So it's not enough to be antisocial and egotistical the selfish programmer must be irresponsible to and I mean that literally like I don't want to be responsible for anything. So World 3 stage 1 the selfish programmer is untethered from operational responsibilities. Their apps should run themselves so that they can go and focus and what they want to be doing the most apt, you know, they end up with lots of operational work that has little to do with the application that sell stuff like security for 4 minutes upgrades and monitoring. And originally the term devops meant developers

responsible for their own apps operations and the idea was well-liked. We saw with automated testing if developers own operations will find ways to simplify and they can go back to focusing on development but it hasn't really worked out that way instead devops has been co-opted by all the large cloud service providers customizable services in this is creative so much new work, but now companies are hiring full-time devops people just like they would know Ops Advocate. I want to focus on programming so my goal is zero

routine operations work. Do to reduce my apps operational costs. My first step was to minimize dependencies follow convention. Try to reduce the number one X servers that I would need, but honestly this only helped a little bit but I really wanted was for somebody just to take care of Ops for me. I want to be able to walk into a store and buy some Ops off the shelf. Fortunately, that's door exists. And it's called Heroku. Not not ya a Roku. Not only is Roku still good. It's better than ever and by helping me be irresponsible of operations work who is the original Spirit of devops

how to run my app server and that I want to run my migrations on every bush. I only pay $7 to keep the app up and $9 for all these automatic add-ons like Roku post. But usually my favorite for Roku features are deploy pipelines and I review apps you can see him at work here. So I'm going to go in to get and change a background from white to purple. Committed to a branch. Are you all my coding in the GitHub web interface against that PR branch? A click in

and I'll see my purple background in. This is such an awesome way to work. You know, you don't have a staging environment or anything like that anymore. You just get to see somebody's PR in action play with color your feedback. It's really awesome in the setup for you after you just create a simple little app. Json file. You tell it what buildpack you're using. What add-ons do you need any script that you need to run after the fact that my script as simple as just running my migrations download some sample data and then create a user so I can go in and test and that's really awesome

and fail to match the developer experience of a $7 Heroku Dyno. It's really cool. But most companies are going to resist no Ops and platforms like a Roku because it's really hard to admit that they're not special unique snowflakes. It is true that no two apps are in the same but your rails taught us that actually share a lot of common problems and crew of operations to Security so why not Outsource that to somebody who specializes in it? So that's why the selfish programmer is untethered by operations. They know that

they're going to go further Faster by focusing on what really what they really want to do right software. All right. Irresponsible stage to the selfish programmers are coding style and on some teams everyone just for the codes their favorite way and that might make people happy at first but inconsistent so you can lead to confusion and conflict later which would slow the team down. Ultimately some things even things we care a lot about just don't matter that much and code formatting

is one example, if the Ruby interpreter doesn't care why should me so that's why it sounds he was trying to normalize on just one style for they start by choosing a way to do things and everyone does their best to conform to it. And then they hope that the code is going to be more consistent and hopefully make it easier for them to own and maintain long-term. But one of the joys of solo coding is that your way is the only way you're finally free to code. However you want but I found that when I'm solo I'm also really fickle my favorite way to code changes all the time. And so whenever my

style changes my code becomes inconsistent and overtime the cross repository that makes it really hard for me to maintain my own projects. So that's why I like consistency. But the problem is that for each individual project, you know, we'll eventually create a custom style configuration and time spent arguing over your lymph wasteful bikeshedding isn't every project is likely to have a different configuration yours going to waste precious brainpower keeping multiple Styles in your head at once. So that's why we created the gym standard. It

wraps real cop with a single configuration that is locked and you're not able to change it so it can't be customized. It's made the CLI real simple. You just run standards to your failures and standard fix to fix them. So trust me. This is not Justin Searles style standard is actually the result of many compromises does this is how I actually prefer to write Ruby code. But the first thing standard does is forced me to use Rockets trailing, at the end of array and hash literals putting space inside my blocks and then using leaving. Santo trailing dots on method James.

Do I write Ruby like this and I don't want it but I value the greater consistency consistency without worrying so much are arguing about every little Rule and best of all if you don't like something you can blame the tool or me instead of one another So the sellers programmers pickle and opinions about unimportant topics change over time. So sometimes it's better just to rely on a tool to help you stay focused on the work. Alright, the final stage. The selfish programmer is unhelpful problems

once and for all then spend time helping others with the same as you over and over again be at work developers are often too far away to help users customer support might sit between them and you know, it supports the first responder to any kind of customer issue, but often, you know, they don't know how to do something. They might can but often developers of the developers might look at it and you know at first glance just kind of creative work around and give it back and that would be handed out to the users. But if the issue workers supports going to look at that and they probably ran

the developer time is very expensive. And so the most likely thing to work around in the passing this happen, we're developers by being totally insulated from user experience is very simple and easy to fix bugs just faster for months and even years because support and sort of just kind of created enough duct tape and and rubber bands to keep everything working. What is the problem never really getting sex? But if you're so low you're exposed to everything every email every tweet every error and because I hate these notifications I'm willing to spend lots of time to make them stop.

For example, I recently had a Time bug not caused by time zones or David types, but by the actual passage of time, I you see I had a controller and I have two different purposes. So I split it up into two new controllers and then blew away the first one now the moment that I deleted that file even though nothing else called it anymore. I suddenly got a ton of bug reports that some people never refresh their browser tabs. So they would load the page. I change the server then their job is supposed to keep calling it and it bugs, but I was

I was still receiving this exact bug report over 6 weeks later. It's why I didn't want to get emails like this ever again. I'm so I needed some way to update the client first and then leave plenty of time for that job after to propagate before I change the server and breaking away for a solo project. How should I do a little to do, for myself like delete this later, but that won't work because he's going to forget about that, and then I'm going to have all those dead code sitting around my system. So I spent a couple hours

and I wrote a little gem called to do or die. It's a reference to an NES game of the same name and it's a single method which just takes a comment and a due date if I plan to believe this. Goodbye June 2019, and as time passes when June comes if I run my server to do or dive going to blow up tell me where to change my code. And now even though you know that Jem took a little while to create since I started using it. I've never had a bag of the same category worker. Look where the Celtics programmer is unhelpful because they understand that if

nobody is bothering them. It must mean they did a good job. So let's just a little bit about how the selfish programmer is antisocial egotistical and irresponsible and my hope is that something here resonated with your work so that you can apply this selfishness to your own practice. Oh crap. If you have any comments or questions, please tweet at me. It send me a DM or an email at my email address just in a test a Bollard Searles on Twitter. Amazon.com. Are you can actually download 4K copies of all of the background artwork from this presentation at that URL.

Again, you might have seen Marlo's talk on remote work yesterday. I used definitely check out Eric Weinstein is talk on interviewing tomorrow after lunch. And you know, if you're interested in a career if your team's just looking for additional senior developers, you can find us a testable. Com or on social things as a testable. And closing. I hope this talk made you consider, you know programming a bit more selfishly and I just want to thank all of you from the bottom of my heart for for sharing some of your time today.

Cackle comments for the website

Buy this talk

Access to the talk “RailsConf 2019 - The Selfish Programmer by Justin Searls”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “RailsConf 2019”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “IT & Technology”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
166
app store, apps, development, google play, mobile, soft

Similar talks

Molly Struve
Lead Site Reliability Engineer at DEV Community
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “RailsConf 2019 - The Selfish Programmer by Justin Searls”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
575 conferences
23117 speakers
8618 hours of content