The ultimate software development tool

Best practices on project management, issue tracking and support

Month: May 2019

A Guide to Developer Mentoring

In this interview with Rachel Ober, Senior Developer at Paperless Post, we discuss developer mentoring. Rachel teaches us the lessons learned from mentoring developers at Paperless Post, General Assembly, Turing School and beyond. These cover how to get started, tips on building successful mentor-mentee relationships, the benefits of mentoring as well as common mistakes. She writes more about teaching and mentoring on her blog.

Transcript

Introduction

Derrick:
Rachel Ober is a Senior Developer at Paperless Post, and an experienced mentor. She’s a Ruby On Rails instructor for General Assembly, Co-organizer of the Write/Speak/Code conferences, and Founder of the New York chapter of RailsBridge. Rachel, thank you so much for joining us today. Do you have a bit to share about yourself?

Rachel:
Sure. I work as a a Senior front-end developer at Paperless Post. I work with a team of five other front-end developers building the different pretty things that you see on our website. I feel that it’s really important to kind of build your team around what you want to see in the work that you do.


“Be fearless and say, ‘Hey, I need help on this!’”


The Benefits of Mentoring

Derrick:
I kind of wanted to focus our conversation a bit around mentoring. You seem to have a lot of experience with that, so what are some of the benefits you’ve seen of mentorship?

Rachel:
Some of the benefits that I’ve seen about mentorship are a two-way street between the mentee and the mentor. For the mentee obviously the biggest benefits that you’ll see is that they will have confidence in their work, they have somebody that they can talk to or just sling questions back and forth. They trust this mentor relationship to be realistic, not just telling you what the mentor thinks the mentee wants to hear. You don’t feel as a mentee, that your trying to impress this other person. It’s a much more open relationship. For the mentor, for me it’s a gigantic reminder of where I’ve come from as well as … I’ve been working with Ruby on Rails now since I think 2005. Wow, that’s like a decade. Every time I meet somebody who’s just learning or is a few years behind me in terms of their career, I learn new ways of thinking about problems. I think mentoring is really a great relationship for both people.

Derrick:
How should people go about getting started with mentoring within a company?

Rachel:
As an individual person, it’s great to talk to people and to first gauge other people who would be interested in participating in something like that. Now at Paperless Post we are pretty equal between our Engineering Department as well as the other people in our company. We have people who design cards, people who are in charge of marketing, so it would be good as an individual to kind of weigh whether or not you’re looking for mentoring for the entire company or just to the Engineering department to figure out what your expectations are and what your goals are for your mentoring program. At that point you might get a group of people together to start some type of pilot program.

I would say even asking HR what their opinions are and whether or not doing some type of mentoring program, an official one, at your company, would be something that they would also support. Obviously having upper management is going to make sure that this is actually going to get integrated into your culture, you company culture. They will support you making sure that you’re following up with them. Maybe it can even be integrated into your review process that might happen once or twice a year.


“I would advise against having your mentor be your manager”


Mentoring Myths

Derrick:
What are some myths that stop people from getting into mentoring?

Rachel:
The biggest one is that people think that they don’t have anything to offer. I think it’s probably tied into Impostor Syndrome. That they think that they would instead hurt the other person maybe, or that they don’t have any accomplishments to really share with a person to be a role model. I think that is definitely not true. My most successful relationship with a mentor, was whenever I did admit to her my weaknesses and saying, “Hey, I had this issue right out of college. I worked at a place for a year and it was a really bad relationship for both ends. It wasn’t the right hire, it wasn’t the right fit.” She was able to admit to me that one of her biggest challenges, and after that mark in our relationship, I saw a great change in her where she believed then that because I had admit to this great failure in my life or this personal failure that I felt about, that she could kind of open up, admit that she was having difficulties in certain areas, and be able to regain her confidence, move forward, and do an excellent job.

I think especially with people who are just learning the program, they have this idea … It’s kind of strange because when I was learning how to be a developer, or learning about development in general, there was very stereotypically, you spend all day in front of the computer. Now it seems like it’s turned into something glamorous, because you have this ability to change your life and to earn a lot of money by becoming a computer software developer. My first class that I taught at General Assembly somebody asked me, “What does your daily life look like at Paperless Post?” I said, “Seriously I spend most of my day trying to fix bugs and most of the time it doesn’t work.” I think I blew his mind.

It was a very interesting experience, but you as a mentor, just by explaining what your daily life is and how you interact with other people on your team, is some really fantastic advice for somebody who is either thinking about becoming a developer, or about to take that step after either graduating college or taking one of these code boot camps. Just giving your experience is very valuable. They want to know how you go about interviews, and obviously if you currently have a job you’ve been through a couple of interviews. Nobody just gives you a job usually. That type of advice is just invaluable for somebody who really has no point in which to reference.

Tips for new Mentors

Derrick:
Any additional tips that you can give for new mentors about the types of things that they should be doing with their mentees to help them learn?

Rachel:
The tips that I give to people that are thinking about getting into mentoring, or people who are looking for mentors, is to really start off the relationship figuring out what the goals of the relationship are. Figuring out how often you’re going to meet, how long these meetings are, whether or not you’re going to have some type of assignment that that this mentee is going to give, and how involved your mentor relationship will be. I’ve had different relationships … Some of it is based on just talking. Talking through issues, and more of the social aspect of becoming a developer or navigating either their job or their learning environment. Other relationships have been very deep into code, working through problems, and learning how to break down problems.

I think figuring that out earlier, it really puts everything out on the table and saying like, “This is what I’m having issues with. This is what I’d like to improve on,” and just kind of like talking about each other, talking about yourself. I feel like it’s very hard at least for me to go in and start getting advice, if I don’t know at least the motivations for the mentee. What they want to learn, how they want to see themselves in a couple months after we’ve been working together.


“Having a whole network of people will really help you share your success in achieving your goals”


Successful Mentor-Mentee Relationships

Derrick:
What do you think are the essential elements of a successful mentor-mentee relationship?

Rachel:
I think that successful elements are definitely meeting regularly. I don’t think kind of having on the fly meetings is really helpful for either person. As a mentee you want to make sure that you’re checking in and goal setting. Making sure these goals are met and that you have this accountability person. Your accountability partner, that you are actually fulfilling the things that you set out to do. I think if you are a mentor and you see that your mentee is not fulfilling these requirements, then you have to have like a really good heart-to-heart and say, “Hey, I’m putting in this time. I’m volunteering, I’m not getting paid for this, and I chose to help you because I really believe that you can do some amazing things.”

Sometimes guilting them helps. If they’re part of a Code school you can contact their teacher or the administration and say, “Hey you know, we set up this relationship and I wanted to check in with them. Have you noticed anything on their side?” You don’t want to be meddling, but you also want to set yourself up for success both as a mentee and as a mentor. Keep assessing the relationship, making sure that it’s working, and also if you are a mentor, being knowlegeable of what they are learning or what their work entails, and anticipating questions that they may have. I think just being yourself and admitting whenever you don’t know what the answer is, or giving them advice on other people to talk to. Just being realistic about yourself, where you’ve been and giving that advice to somebody else, is really the crux of a relationship like that.

Finding Mentors and Mentees

Derrick:
Where can people find mentors, or people to mentor?

Rachel:
That is a very interesting problem. I don’t think it’s easy to find a mentor, because there’s a certain level of trust and understanding. For me, I have always mentored other people. I’ve found mentees with volunteering for Code schools. I’ve mentored students from the Turing School out in Colorado, which may sound odd since I’m in New York city, but I’ve been fairly successful working with people over Google Hangouts and Screen Hero, and Slack, and just leaving myself available over text message and phone. I’ve also mentored people either through organizations that I work through … I would say that’s mentorship even if maybe you haven’t said exactly what that relationship is, or have a steady schedule. Also through the classes that I’ve taught at General Assembly. People asked to meet regularly, they want really advice on where to go next. They become voracious and they want to learn as much as they can.

For me, I’ve been searching for my own mentor for awhile. I’m particularly looking for somebody who is five to ten years ahead of me in their career. It took me a little while to kind of formulate the idea of what I was looking for in my relationship. As a woman it was important for me to find a woman who was doing the type of thing I wanted to be doing. I had to really extrapolate and think about what I wanted to be doing in five to ten years. Really be honest with myself. Where am I going to be in my family life, where am I going to be maybe in the country. Assess these things that are important to you, and then see if there is somebody out there that you really admire and just ask them, and you don’t have to limit this to one person either.

Having a whole network of people will really help you share your success in achieving your goals, because you have more accountability partners and more opinions. There’s a couple online services as well. For women there is a site called Glass-breakers, which will link up people, via the LinkedIn Network. There I’ve had a couple introductions, and I actually met somebody in person who happened to be on a business trip from London. We had dinner and it was amazing how well we connected. I would be fearless and say, “Hey, I need help on this,” and admit that you need help, and these natural relationships will form.

Derrick:
Is there something in that relationship that says your mentor should or should not be your manager?

Rachel:
I would advise against having your mentor be your manager. Here we do have Technical Managers who are in charge of making sure our project is on time, making sure that everybody’s being productive, and basically are leading the projects, leading the teams. They’re also in charge of writing reviews for the team members. We then have other people who are available such as myself, who are really focused on making sure that the other employees are happy, they’re doing the type of work they want, and then also if there’s something they need to get off their chest, it’s a safe environment because you’re talking to somebody who isn’t reporting on you or needs to also … They’re kind of the neutral Switzerland or something. They’re to necessarily involved in the review process of you and your team, but they’re there to help focus on your happiness and the growth of your career.

I think whenever you’re the manager you have to constantly have that balance of the best interest of the company and the person, whereas I think an independent party really is concentrating on the person. It doesn’t mean that this relationship with your manager is bad, it just means that maybe you also need to take in a mentor who’s not in a manager role.

Derrick:
Rachel I think this was really great conversation. I hope a lot of people take the next steps to either find a mentor or become a mentor.

Rachel:
Great, thank you for having me.

The Problems with Open Source (and How to Fix Them) – Interview with Justin Searls

In this interview with Justin Searls, Co-Founder at development agency Test Double, we discuss issues in open source software and what we can do about them. Justin raises problems for both consumers and contributors – like managing hundreds of dependencies to security issues and burnt-out maintainers. We dive into the efforts being made to address these and what you can do too.

Justin discusses issues like this and software development more generally on his blog.

Content and Timings

  • Introduction (0:00)
  • Open Source convenience, long-term fragility (1:33)
  • Who is Auditing Open Source Code? (5:17)
  • The Rollercoaster Ride of Maintaining Open Source Projects (7:38)
  • Recruiting More and Better Contributors (11:18)
  • Improving Communication in Open Source (12:42)
  • How Can We Help? (14:35)

Transcript

Introduction

Derrick:
Justin Searls is co-founder of Test Double. A software development agency based in Columbus, Ohio. Through his work Justin uses and contributes to a number of open source tools, and also speaks at conferences about a range of software development topics, including the talk The Social Coding Contract, which highlights some issues he sees in open source projects.

Justin, Thank you so much for taking time to join us today, really appreciate. Do you have any more to add about yourself?

Justin:
There’s a lot of brokenness around us, and I think the talk that you referenced, The Social Coding Contract, is really just putting a lens on a lot of brokenness in open source. But I’m not just here to shout at the clouds and complain about stuff. I think that by building awareness we can make it better.


“In an open source team you have like a dozen people who all want to be point guard”


Derrick:
So your talk raises a number of issues in open source development, both for consumers dealing with dependency issues, and for maintainers resulting in burnout. But what lead you to want to raise these issues?

Justin:
I think that when you really really distill things down, boil it down to just a kinda core essence. The answer to that question, is that our industry has organized itself around, essentially a lie, and that lie is that faster equals better. Anything we can do to like, faster to build an app, faster to ship into production, devs that slingcode faster than slower devs, or 10X better than … All of our orientation of how, you know technology is sold and described, and glorified in our culture, is all about how like how fast it is how fast people get stuff done. But the overall attention span is so brief that we just tend not to focus on problems.

Derrick:
Lets dive into a couple of these issues, you say that those building with opensource optimize for convenience, but often at the cost of long-term fragility. What do you mean by that, and has this impacted your projects.

Justin:
By fragility there … What I don’t mean is that there is some sort of cabal of open source developers trying to make a mess for you. What I really mean is that when you ship something into production these days, odds are you’re running like a little tiny layer, 10 percent or less of the code that’s getting executed in production is stuff that you wrote. Most of it is a mountain high of application dependencies that you stand on top of. Some directly, some transitively that got pulled in via those other dependencies. It’s a lot of stuff that frankly we don’t understand really well. And that’s fine for getting started, because obviously you gotta be competitive, and if somebody else can get a prototype out the door quickly, you can get really fast feedback. You know?

There’s a lot to be gained from it, we just need to move cautiously to understand, okay so it’s been 3 months, it’s been 6 months. Lets actively look at how these dependencies have been serving us. Have they been a pain to use, have any died or gone out of maintenance. Like what’s the influence that they’ve had on our, the design of our code. Are we really just like writing cookie cutter code to satisfy all the APIs that we are depending on or are we really growing a domain model that very nicely fits like a glove the problem that our application’s trying to solve.

Those are the sorts of things that, you know I would kinda call fragility that’s baked in to this process of looking for something to help get us a quick start. Another facet of this that’s really interesting to me is that coming from the ruby community, where ruby on rails was really huge, or became huge almost a decade ago now. That was one big monolithic framework and that was very difficult for me to start my own framework, because I would push it up, but then I had n plus one queries everywhere. All sorts of like pain of not knowing how to it, a magical little thing. And I could remediate that on one project, and it would take a long time, and everyone would pay the price of learning rails. But on subsequent ones we could at least use that knowledge.

But nowadays I think the trend is so anti-framework, and so pro-modularization, tiny libraries that all do their own thing. We’ve all become effectively framework maintainers. Not to say everyone’s inventing their own, but we’re like curators now of like this manifest of here’s my thirty dependencies, and no one else in the world will have all thirty dependencies at exactly the same versions that you do. Which means that now the onus is on you to make sure that they all work together correctly, and if there is any interplay between the two of them that doesn’t, it is up to each project team who’s tasked with building an application to also be responsible for troubleshooting two potentially divergent dependencies that are stepping on one another.

Derrick:
It’s definitely an interesting perspective, I haven’t thought of that myself, as a curator of frameworks.

Justin:
Yep, and it’s not like small is bad and that big monolithic stuff is good. It’s just these are the source of costs and the responsibilities and the roles that we should be thinking about. That go with maintaining something built that way.

After five to six years of working with a lot of, you know open source technology projects you start to see a lot of patterns, just do basic pattern recognition. Be like oh we’re finding like writing adapters for this third party thing is really really hard, or its API is seeping all over our project. Like how can we guard our self, and push that out, build some scar tissue between us and that dependency, because it has been found to be kinda problematic.

All those sorta good habits I think tend to grow organically, but then can only happen if people have an awareness that all these dependencies leaking all over there stuff lead design problems long term.

Derrick:
We often approach using popular open source libraries with the assumption of security, because anyone can read them, and with trust because they have a number of respected contributors. But you don’t buy that, why is this?

Justin:
The concept that you’re alluding to, is introduced in the book called The Cathedral and the Bazaar, like fifteen years ago, maybe longer. But that was written in a time when, when most people were thinking about open source they’re thinking about really big operating systems, like Windows versus Unix. Like a total black box versus this thing that is like one or two or three major big projects that have tens of thousands of developers looking at really closely. And over the last fifteen years, everything’s inverted. Now GitHub hosts hundreds of thousands open source projects.

I think at some point we probably eclipsed the point where there were literally more libraries being used, than eyeballs looking at the actual source code of other people’s open source. So in theory that would work but the problem is that there is more projects then there are eyeballs.

The other thing that I think effects this is the stack, the open source stack that we stand on gets a little taller every year. Every year we find some new common solution to a well known problem, and we stand on it. And fifteen years ago, twenty years ago, when people were starting to grow thoughts about what open source would mean for security, well you know like openness itself for example, like you know like that’s a pretty cool library, like I’m gonna use that for how I do my network securely. But now it’s such a given that everything depends on OpenSSL, that we … You know it’s mature, its mostly settled down, there’s not a lot of maintainers, it’s not a sexy thing to invest in from a marketing perspective if you’re Facebook or Google. So it mostly just gets no attention.

Even if you are a really big company, and you understand that your openness is all working is critical to your business. You know that it’s like a Mexican standoff where every company in the world, they all depend on it. So it’s certainly like, it’s very important that someone be auditing the security of a fundamental thing like that. But it’s nobodies responsibility to do that, and no one feels that accountability. So I think that’s where we’ve really fallen on our face, where something like Shellshock happens to Bash, and it’s a program almost every developer uses, and lots of different internet of things stuff use. But zero people feel like it’s my job to go on the weekend and read up on, you know Bash to make sure that it is secure.

Derrick:
You describe the life of an open source project maintainer to be something of a roller coaster ride, that all too often ends with the maintainer getting burnt out. Why do you think that this is commonly the case?

Justin:
On the one hand, we kinda glamorize prolific open source authors. There’s maybe hundreds of thousands of open source projects out there but there are a handful of people that are like, Hey when I’m doing some node stuff I’m gonna look for a library that TJ Hallowaychuck posted, because he’s got a lot of them, and his other ones were pretty good, so I’ll use this one too. Of course he up and left node one day, which was problematic for anyone that lived in his stack. We don’t do this intentionally, we don’t seek to live in this celebrity culture, its just when there are so many options out there, we need all the tribal markers for quality that we can find, And that person wrote a good thing, and I like their approach to something else, so I’m gonna use all there stuff. And that’s how that sorta power accrues.

Now, the second phenomena which I think is really interesting, is as personality drives so much open source adoption the asymmetric relationships just fail to scale. Like an illustration that I was thinking of is like imagine that you found a golden lemon, and it could squeeze and infinite amount of juice, so you started an open source lemonade stand. And so you squeeze all the lemonade from that lemon all day long, for anyone who wants it. And the early adopters of your lemonade stand are gonna be like whoa you’re brilliant, this is amazing. Of course they’re gonna get sick of the lemonade and move on eventually. But once the word gets out, even though you’ll have gotten that initial fame and excitement of getting a lot of positive attention; pretty soon the line’s gonna be so long that the upper bound on how much lemonade comes out is your own physical laborious painful labor. And at that point you’re at a crossroads, you have to decide like, and this is analogous to an opensource maintainer. It’s like I don’t get any distinct joy out of this anymore, I’m mostly just doing work for people for free, and they don’t really appreciate it because they’re used to it now.

So do I continue out some sort of misplace sense of duty, or do I just quit and leave people in a lurch. I think that’s how a lot of open source projects slowly atrophy and die.

Derrick:
How do you think we should go about fixing this?

Justin:
I think that the successful long-term sustainable open source projects are ones where a community formed around them in proportion to their growth and success. And I think all parties involved need to be A, recognize that, acknowledge that, and B accept some amount of responsibility other than treating open source like a corporate welfare program. Right, so if I’m a maintainer I acknowledge that now, after writing this talk and thinking about this a lot is like, okay so this project is a hundred stars, like I really shouldn’t be the only owner on this repo or this NPM library, or this ruby gem. Lets pull in a couple other owners because other people are joining and like oh this project is a thousand stars, like lets look at a code of conduct, a governance model, you know some kinda mission statement for what this project’s about, the core tenants.

You know oh it’s at ten thousand stars, like we should probably start to have like a technical committee so I get out of the role of dictator for life. Because it’s now way bigger than what I meant for it to be. So it’s a bit of humility right, like seeding control gradually, to avoid that burn out. But then from the perspective of users, they need to be actively seeking, and accepting like, hey you know I should be contributing back to this, and I should work with my employer to make sure that I have the time to contribute back to the projects that we use, that are interesting to me. So that they have the support that they need, so that they don’t just wither on the vine and die even though hundreds or thousands of applications might continue to depend on them.


“There is never going to be a day where you feel like your thing is ready enough for public consumption… so please just publish”


Derrick:
What else can project maintainers do to recruit more, and better contributors, and to reduce friction for those interested and contributing?

Justin:
I really like the idea of an imagined application that was like a match.com for putting together people that have open source projects that need additional contributors, maybe they have a lot of issues, maybe like I said they’re getting more popular and they recognize this need. With people who are looking to work on open source. Maybe they want the additional visibility or the prominence that comes from having a lot of open source stuff. Maybe they just want something to program on. Maybe they just want to improve their skills.

Whatever the reason, it would be really cool if an application, say used Oauth, or a storage of your various credentials to be like hey you use this library and that library author is looking for people. Or hey you write a lot of node JS and this person’s got a node JS project that’s got this many stars, and he’s desperate for a maintainer. Something to connect these people, because I think that if you look at the network graph of people who are publishing open source, it’s too small for them to try to solve it by you know, simply tweeting out or going to a user group and being like, hey will someone please maintain this. Because usually by the time that they know to ask for help, it’s late enough that that project is no longer appealing, like its probably mostly settled down and the only work left to do is to put up with all of the random people who want basically free tech support.

Those are some ideas, but you know short of that it’s hard, it’s better to try and solve that early than solve that late.

Derrick:
So in problematic projects at work, we use techniques like improving documentation, retrospectives, stand ups, pair programming to overcome some of these problems. Yet you rarely see them applied in open source projects. Do you think there is a role for these, and other ways of improving communication between maintainers, contributors, and users?

Justin:
So like comparing like a product team and a business versus an open source team. It’s almost like in a product team you’ll have role players who specialize in one area or the other. In an open source team you have like a dozen people who all want to be point guard. They don’t necessarily have any incentive or organization to be a role player that slots into just like one particular aspect of the project. Unless there is somebody or some group of people who are smart enough and experienced enough to be able to … Like you just did, carve out all of these individual responsibilities. Like if we don’t do these things problems are gonna happen. Like we have to individually justify because we don’t have some boss, we don’t have a paycheck coming typically. We need to justify for ourselves why these activities are important.

Then some of them are just shit work compared to other stuff. Like everyone wants to be the genius that gets to code a thing, and gets to be famous for building it. But if you look at somebody, maybe they are a great writer, and they are a great teacher and instructor. And if they wrote the documentation pages, then that would be fantastic for the community. But that doesn’t necessarily get the same accolades or glory. And so it’s contingent on everyone else on the team to lift that person up, to point out how great they are and how they’re helping.

That’s what I see on really successful open source teams. Is giving people a reason to fill those roles that isn’t just about money. Because once you put money into it, it might as well be a starupified or productified open source, in kinda you know name but not spirit only project.

Derrick:
What do you think of initiatives like Todo group and Ruby together, and what more do you think companies who use open source components can be doing?

Justin:
I’m friends with Brandon Keepers at Github, who’s done a lot of there work through Todo group, and it sounds like in many ways, its goal is to solve a lot of the systemic problems, or at least address as a bunch of companies realizing like hey none of us individually have an individual interest in being the one to own these shared concerns, like security audits. But we understand whenever there is one we all have a huge business risk to that.

So I love the idea of them coming together, putting a little bit of funding behind it, and seeing where it goes. I don’t think that it’s gonna turn into this thing where it’s developing a lot of standards and process that other people are gonna feel beholden to. You know they might publish some examples like an example code of conduct that you could use, or something like that to help people get started.

But I think its biggest point of value is gonna be how do we solve some of these interweaving problems, that no individual person feels responsible for. When you think organizations like Ruby Together … I don’t very much about Ruby Together per se or properly, but in conversations I’ve had with other people about things like GitTip or efforts to try to put money into projects that are commonly used as support. On one hand like sponsorships like hey we’re Ruby Gems, we need hosting, you know. That is a real clear cost. Where it gets a little muddy is … I think a lot of people have great intrinsic motivators for working on open source, and when you just kind of like put a bounty on like, hey if you get this feature done, or individual sponsorships for like, hey I want this feature, as a company in this open source thing so we’re just gonna fund two months of the developer’s time.

A lot of those are really interesting, and some of them might scale, and some of them might work. But it’s important to know that there’s still this impedance mismatch. The reason anyone starts writing an open source thing isn’t to get paid, its because it scratches an itch or it’s something that they found interesting. There’s a real risk that once you start throwing money at it, whether it’s at the individual or at the specific features and issues. You’re probably going to change the incentive structure, and alter the course of where that project goes.

So I’m a little bit more cautious around the argument that open source work is labor too, and we need to be paying directly for people’s open source labor, through some kind of like patron model. Another example of that that stands out to me, is I’ve got a friend who is a very prolific open source developer, and he could totally start a Kickstarter tomorrow and raise two hundred thousand dollars a year, if he wanted. To just do open source, and he won’t do it because he’s a smart guy, and he know that as soon as he gets however many five dollar donations it takes to get up to that number. Those are gonna act like customers, like if they don’t get the feature that they want or they don’t get their bug fixed, they’re all gonna come knocking down. Then it’s that lemonade stand problem again. Of not only do they expect the free lemonade but it was five dollar lemonade, and they paid for it and they want a refund.

So all of these things sound like solutions, but I don’t think that any of them are ever going to solve the problem of code that’s written for an egalitarian reason or a non-financially motivated reason can’t just be solved by throwing dollars at it.


“Our industry has organized itself around, essentially a lie… that faster equals better”


Derrick:
Can you recommend any resources to those wanting to learn more about running sustainable open source projects, or those wanting to contribute to open source more effectively?

Justin:
So first, when I meet people at conferences or user groups, a lot of them will come up to me, and its like a hallway confession almost. Like hey man I like all your open source stuff and I would totally open source stuff too, I’ve got this thing that I’ve been working on for like five years, but its not ready yet, its not ready to be open sourced yet. I just want to say you know … Okay bye. So like clearly they felt the urge to come and talk to me about there not yet open source thing. But they have this kind of like intention towards contributing.

What I always tell them is that there is never going to be a day where you feel like your thing is ready enough for public consumption, that you’re just gonna flick from private to public and ready the flood gates. First of all, I probably have like 200 or 300 repositories between test double and my personal account. That calculation is expensive, I just default to open sourcing absolutely everything.

You’ve never heard of 99% of my repositories, I guarantee it, because most of them weren’t that useful, maybe didn’t go great, maybe it just didn’t get viral, and a couple others did. The only reason that those ones did get successful, is because I was defaulting to open sourcing everything that I do that doesn’t have like a strict business model in front of it.

So that’s what I tell people about getting started and open sourcing. The first place is like if you just publish everything openly, that’s going to look real good when you have all this stuff to show, even if it’s not perfect.

Oh and don’t worry about people looking at your code and judging you, because a lot of people say they read open source, but like we discussed earlier about security, no one actually reads open source. Like if there’s a bug or something they look at it, but no one’s going to read your code. They’re going to see that you have thirty repositories, and that presumably they work if they have a little green badge at the top.

So please just publish. The other bit of advice about like resources for successful, sustainable, long-term, like once something’s been successful where do you look at. I don’t think that book’s been written, I don’t think that there’s a starter pack for how to build a community. At least not in the open source world, but what I would look at, is look at the non vendor-backed very successful projects. The two that are most relevant to my personal technical experience is Ruby on Rails, and even more so EmberJS. When you look at Ember, like yes there are a handful of agencies, that kinda back it and firmly sponsor it. Like obviously Tilde is the Ember company. But they’re not Oracle, there not Facebook or Google. There a smaller group of developers that just care a lot about making a ten year framework, and putting in place all of the structure that they need to build the community around it. Now look at it, there are Ember meetups, in I think like thirty different cities, we have one here in Columbus.

There’s a very strong affinity and a strong sense of ownership by even people who just use Ember. So they’ve done a great job of leveling people up, encouraging contribution, and encouraging engagement really at every level. So look at everything that they’re doing.

Derrick:
Justin, thank you so much for joining us today.

Justin:
Thanks so much for having me, I really appreciate it.

Anyone watching this, and wants to get in touch with me directly, please don’t be shy, just justin at testdouble dot com, I’d be happy to talk to you.

Going Beyond Code to Become a Better Programmer – Interview with Pete Goodliffe

In this interview with Pete Goodliffe, author of ‘Becoming a Better Programmer‘, we dive into issues that go beyond code and separate the good from the great developers. We cover things like attitude, communication skills, managing complexity and what you can do to learn more and keep your skills up to date.

Transcript

Introduction

Derrick:
Pete Goodliffe is a programmer and software development writer, perhaps best known for his software development book, ‘Code Craft’. He speaks regularly at conferences on software development topics and recently published ‘Becoming a Better Programmer: A Handbook for People Who Care About Code’. Pete, thank you so much for joining us. Would you like to share a bit about yourself?

About Pete

Pete:
Sure. I’m a geek. I’m a developer. I like to say I’m a conscientious coder, making the world better one line of code at a time. I am a regular magazine columnist. I’ve been writing a column for more than 15 years now, which is probably some kind of record, I suspect. My day job, I’m a coder. I work in a really awesome team making fun stuff. I’m a musician and I get the opportunity to write code for musical instruments.

A Great Developer’s Attitude

Derrick:
In the book, Becoming a Better Programmer, you say the real difference between adequate programmers and great programmers is attitude. What are the characteristics of a great programming attitude?

Pete:
The standout difference between the really good coders that I’ve worked with and the guys that aren’t so great, is attitude. It’s not a hand-wavey thing. I’ve worked with guys who know technology and who know the idioms, and how to do all this stuff. If they don’t have the right attitude they’re just not effective programmers and they’re not great guys to work with. The kind of stuff I’m talking about here, is humility. You don’t want to work with guys who think they know it all but don’t. Being humble is the key thing.

It doesn’t mean that’s an excuse to not know stuff, but just not believing that you’re better than you are. Specifically, being in a state of constant learning, which I guess ties in with humility, so constantly looking for new stuff, absorbing new knowledge, wanting to learn off other people, the desire to do the best thing you can. It doesn’t necessarily mean be a perfectionist and wanting to make everything perfect before you ship. It’s doing the best you can in the time you have, with the resources you have. That kind of attitude really drives through to great code, great products rather than sloppy work.


“I’ll mis-quote Sartre and say ‘Hell is other people’s code’”


Write Less Code

Derrick:
You’re an advocate for writing less code. Why is this and how can programmers actively work on coding more concisely?

Pete:
Yeah, less code. It seems kind of counter-intuitive for a coder but I think most old-hands know what talking about. It’s kind of the case of working smarter not harder. It’s entirely possible to write thousands of lines of code and achieve nothing in it. Think about it, no unnecessary logic, don’t write stuff that doesn’t need to be said, don’t write verbose code. Sometimes you can stretch out boolean expressions into massive if statements which just hide what is being said.

It’s really a pointless comment, we’ve all seen that haven’t we, code with an essay, and then the function body is really small. Somewhere in the essay there’s some important information but you didn’t need the fifteen paragraphs of comments. No pointless comments, the code just does what it does. The writing of simple but not simplistic code. If you don’t write enough code, it doesn’t do what it’s supposed to do, but just avoiding all those points of needless generality. Don’t make abstracts interfaces, don’t make deep hierarchies that don’t need to be extended, if you don’t need to extend them.

Communicating Effectively

Derrick:
For most professional programmers, development is a social activity in which communication is key, how can programmers begin to communicate more effectively?

Pete:
Code is communication. You’re communicating not just to the computer, you are communicating to other people writing the code. Even if you are working by yourself, you are communicating to yourself in two years time when you pick up the same section of code. It’s a skill, and it’s something you learn, and it’s something you consciously practice. I don’t know of courses, Uni courses or practical courses that really focus on something that’s really quite an important skill for programmers. It’s something that you need to consciously practice, you need to consciously work on, you need to be consciously aware of.

It’s true some people come out the gate better placed than others. Some people can talk well, some people are shy and retiring, but that doesn’t necessarily mean you are stuck like that. That doesn’t necessarily make you a bad communicator. Some people communicate better in different media and it’s worth bearing that in mind. Some guys are really great on email, they can write concise, clear descriptions, they can follow a line of argument writing and explaining something really well. Other people struggle to put it together in words. Learning how you communicate well, playing to your own strengths, then picking the right medium.

Handling Complexity

Derrick:
What are some ways developers can approach managing complexity in software development?

Pete:
A key thing to understand is the difference between necessary complexity and unnecessary complexity. The reason people pay us to write software, unless we’re doing it for fun, is because there’s a complicated problem that needs to be solved. There is some level of necessary level of complexity in software engineering and we have to embrace and understand. The problem is the unnecessary complexity. You can take something, a problem you need to solve, add a little bit of complexity, but then if you wrap it up in class design and higher up it reveals itself in architecture.

One thing I know about well crafted software that basically has the necessary complexity but none of the unnecessary complexity is when I look at it, it looks obvious. That is the key hallmark of some excellent code. You look at it and you just think, “You’ve been working on that for a while” and I look at it and I go, “That’s clearly right.” And you know it wasn’t simple to write. When you look at it the solution’s simple, the shape is simple. All I can say is, that’s what we should strive for.


“I have learned the most in my career when I have been around excellent people”


Derrick:
What are some things developers can do to tackle messy or bad code bases?

Pete:
The most important thing is when you get into your codebase, is to ask people. I see so many developers who just won’t sort of swallow their pride and say, “I don’t quite know what this is doing, but I know Fred over there does. I’ll just go talk to Fred about it.” Often those little bit of insights give you a super fast route through something intractable, a little explanation sort of takes you in there. I’ll mis-quote Sartre and say “Hell is other people’s code.” We all kind of go into that, I do this, and I really struggle with this. I pick up some code, I look at it, that’s a bit dodgy isn’t it. “I really wouldn’t do it like that, what were they thinking, they must be idiots!”

Then my code, I think it’s great. I understand it perfectly, but then somebody else picks it up, they’ll make that same judgement call on my code. What I think is their terrible hack, is actually some pragmatic thing they did for very good reason. When you’re reading messy code, looking at messy code, enter with humility. Nobody really goes out of their way to write badly. Nobody goes out of their way to write messy code, in general. I can’t say that I’ve found anyone that really tried to ruin a project. Approach code with that attitude.

The retrospective prime directive, I can’t remember how it goes, we truly believe everyone did the best they could to the best of their abilities at the time given what they knew, etc., etc. This stops you from making judgement calls, stops you from saying oh, I’m going to rip this whole thing out and start again. This teaches you humility to look a little deeper first.


“The standout difference between the really good coders… and the guys that aren’t so great, is attitude”


Keeping Your Skills Up to Date

Derrick:
The stuff that we work with is constantly changing and it’s all too easy to find yourself becoming something of a coding dinosaur. What can programmers do to ensure that they keep learning and developing their skills?

Pete:
If we value our careers and our skill sets, then this is something you should really be caring about. This is something I find really challenging for myself right now as well. The things I’m focusing on and learning right now are not necessarily coding-related stuff. I’m challenged with learning management, some high-level decision and tactical thinking on a project, rather than dipping into low-level coding stuff. Which is also really fun, but it does mean that I’m pulled away from thinking about the lower-level technical stuff. I want to challenge myself, not get stale and not become that coding dinosaur.

It’s interesting because I know the tools that I know well, and I do use them regularly, but it is really easy to become stale if I’m not pushing the envelope on my technical skills. The biggest take away I guess though is passion. If you don’t want to become a coding dinosaur you probably won’t, because you care about it enough that you will learn, you will read, you will spend time, you will look at web casts, whatever. If you don’t have the desire to learn. If you don’t have the motivation to do it, that’s when you stagnate. That’s when you become a dinosaur.

Recommended Resources

Derrick:
What are some resources you can recommend for those seeking to become better programmers?

Pete:
The biggest thing for me, and that I have done personally and continue to do, is to sit at the feet of great coders. I have learned the most in my career when I have been around excellent people who I can learn off of. Whose skills can rub off on me and I have moved jobs. I have moved myself physically to be able to work with those guys. If you have the liberty to do that, do that. It’s joining in those conversations replying on Twitter, blogging yourself, joining the local user-groups, and all that good stuff.

You want to become a better programmer? Again it’s the want to be a better programmer, and just stoking that passion. I’m enthusiastic. I love this stuff. If you have an enthusiasm, that passion for programming, it tells out in the code that you write.

Derrick:
Really appreciate your passion today. We can definitely see it, and we hope the viewers enjoy it.

Pete:
Excellent. Thank you. Cool.