Congrats! I remember seeing posts from you now and then about how you were learning programming. (IIRC, your first contact with programming was for the demo to get your track jacket?) It's great that you kept at it.
My first task was to add a dismiss button on a Javascript popup. I thought the task would be easy, but each page actually has dozens of files of code fitting together to make a page work– style sheets, controllers, distributed all around the code base. (…) Instead of being off-put by how long it took, or being overly sympathetic, he just said, “Yup. That’s what development is. It’s very frustrating until it works.”
I'm currently in a similar situation, working on a project with a guy who uses libraries and frameworks I know very little about and it honestly frustrates me. I've had other things to do on the project so far, so I've postponed digging into it.
But it makes me wonder if that's how things should be. Often you're fine once you're beyond the breaking waves of setting up your environment and getting a grasp on the codebase, but before that, it can be very frustrating… especially, when you want to implement something, that you theoretically know exactly what you want and what you need, and you get slowed down by some problem with library incompatibilities or what not.
I think the lecture is broader here. Frustration is really at the core of programming. And whenever you're frustrated, thats a wonderful lession ahead of you in understanding what makes the systems tick that you take for granted.
I've recently had the pleasure to drill down (from C) to single machine instructions in my quest to understand why a conditional branch was seemingly having no effect, on an architecture that I couldn't debug on. As it turns out, the compiler would sometimes use a memory addressing scheme that wasn't supported on this particular architecture. I had to work around this bug by writing assembly that correctly accesses the memory.
It's incredibly frustrating when you end up at a point where the only abstraction (and seemingly faulty) layer below you is nanometer-sized transistors. And all the more rewarding when you reveal the actual problem and get to extend your knowledge.
(Of course, this doesn't really apply to all the ridiculous pain points that annoy us by design. Things like browser compatibility come to mind.)
I can certainly enjoy figuring out what's wrong sometimes (and unravel the whole string of events: "oh now that makes sense: this was happening which made this and that behave that way") and I the satisfaction you're referring to; but other times, it's just so far removed from the real task at hand that it's not even funny.
A recent example would be when I was trying to set up my local environment with virtualenv, whose whole purpose is to make that easy. Everything seems fine but pip (Python package manager) was throwing errors. The culprit was that virtualenv creates Python scripts in the local directory with a hashbang for a local version of Python. The thing, it turned out, is that hashbangs don't work when there's a space in the path. And there was a space in my path because I wanted to use Box's sync folder which (stupidly I must say) is called "Box Documents". Now I know.
Long story short, the point is that I wasn't trying to debug virtualenv but had to dig deeper than I wanted into it just to get started on the problems I created. :)
Though you're right: just recalling this, I have a feeling of victory over the problem.
I think the biggest lesson for me was that in programming things aren't necessarily there for a reason. Method and class names are arbitrary and part of the "creative" side of development. One of the best skills to learn is to read arbitrary code and be able to pull out the concepts and ignore the "design" on top.
I said this elsewhere already, but I've been really proud to see Twilio take steps such as this one to bring more people (and more women in particular) into programming. Not being a part of the web team, I've only watched from the sidelines as Renee, who's consistently been in the office before I arrive in the morning and after I roll out in the evening, has worked to master a whole slew of technologies, and to ship new, non-trivial features for our customers.
I'm really not sure how the two facts we see here -- of people working exceptionally hard to better themselves, and of a company going out of its way to help people do that -- have to do with a bubble. It's hardly a new idea that companies do better financially when they help their employees learn to do work that they couldn't do before, or to do it better.
As the technology community, it's in all our interest to help people learn things they couldn't do before. Twilio's story is one example. Other great ones include RailsBridge, PyLadies, the Boston Python Workshop, and PyStar. Let's do more of this!
This makes me love Twilio even more :D I wish more companies would realize the benefit of cultivating talent from within instead of mining other companies for "rockstars"
My first job was at a company that did exactly this. Most of the developer staff came in the same way I did: part time college student software tester/tech support.
It was only after the company was purchased by a company with a very different mindset did I realize that this wasn't universal. This makes me just love Twilio a little bit more.
Congrats, that's a great move and I'd think a good decision for Twilio. My product manager came from our Customer Service team and is the best PM I've had. I think you nailed it when saying programmers don't need to be brilliant, but rather "it’s more important that you’re diligent and a methodical problem-solver."
Especially when you're working on an existing product. Maybe it took some brilliance to come up with the first version of Google, but once something grows into a bajillion lines of code with tens or hundreds of people all working on little parts of it, brilliance will only get you so far.
The company I'm a contractor for originally hired me as a customer support agent. 9 years later, I'm one of the lead developers. Keep up the good work!
Renee has handled a good portion of our support tickets over the years and does a fantastic job. It's refreshing to have someone treat even the smallest problem of yours so personally - making sure everything is resolved to your satisfaction. It's huge having someone who's overseen thousands of customer tickets becoming directly involved in the engineering process. Good luck Renee!
I consider myself to be a relatively experienced developer, and even still, reading this blog post really lifted my spirits.
I write code for a living, and even though no one has ever told me they weren't happy with my performance, the constant influx of new techniques, languages, algorithms, and systems in the programming world have always made me feel like an inferior developer. I constantly feel like there's so much to learn, that I can't possibly be good, as if the only worthy developers in the world are the top 500 geniuses that work for Google and Facebook and are somehow capable of magically knowing everything.
Knowing that this isn't the case, and that companies like Twilio are finding value in employees with skill sets much narrower than mine, is a good feeling. It's also really nice to know that they're open minded to the point that they respect this guy's talents as a developer just as much as they did as a customer service rep. #thehighroad
A more cynical quip I like to use is that the corollary to "you're never the smartest guy in the world" is "you're never the dumbest guy in the world".
The more advanced you get in your field, the more you understand how little you really know. I feel like this every day. It's easy to forget that to a ton of people you're still a guy/gal who works magical wonders with computers.
Very cool. I think that stories like this one contradict the often quoted advice to hire only rock star hackers in a good way. People aren't born A,B, or, C players - they learn those skills over time.
For years I hired developers and told myself I was incapable of doing what they did, never tried to learn. After the job market got hot and I was having to pay good devs $100+/hour I decided I had to finally learn myself. Less than six months later I can now do 80% of what I used to pay people to do for me and 100% understand what they were doing from a high level and why. In another year I think I'll probably be a better developer than most of the people I've hired in the past (mostly because I sucked at hiring good devs because I had no idea how to evaluate their skills).
There's nothing I've had to learn that was especially difficult or that requires someone a lot smarter than me or a lot better at math etc. It just requires persistence and a willingness to put up with frustration until you finally solve problems.
My only regret is that I didn't start learning 5+ years ago.
My first task was to add a dismiss button on a Javascript popup. I thought the task would be easy, but each page actually has dozens of files of code fitting together to make a page work– style sheets, controllers, distributed all around the code base. (…) Instead of being off-put by how long it took, or being overly sympathetic, he just said, “Yup. That’s what development is. It’s very frustrating until it works.”
I'm currently in a similar situation, working on a project with a guy who uses libraries and frameworks I know very little about and it honestly frustrates me. I've had other things to do on the project so far, so I've postponed digging into it.
But it makes me wonder if that's how things should be. Often you're fine once you're beyond the breaking waves of setting up your environment and getting a grasp on the codebase, but before that, it can be very frustrating… especially, when you want to implement something, that you theoretically know exactly what you want and what you need, and you get slowed down by some problem with library incompatibilities or what not.