How to be a Great Developer

I’ve shamefully ripped off the title for this blog post from what I expect will be a phenomenal session given by Ed Finkler at php[tek] 2014. Sadly, I haven’t seen the session and may not be present at the conference. However, I’ve spoken with Ed and seen him give sessions on several occasions, so I know he sets the bar pretty high.

If you’ve not considered attending the conference and his session, I highly recommend doing so. Ed has plenty of insightful things to say about being a great developer. Today, the subject coincidentally crossed my mind and I realized I had a few things to say on the matter that may also prove useful to others.

Humility

A friend of mine who had some previous programming experience, but was not a developer, recently set out to learn more about what it’s like to be one. This led to many conversations between the two of us that reiterated a few things to me: this person is very intelligent and very determined, and while they felt quite out of their element in this pursuit, they were iteratively making progress toward their goal of understanding what being a developer is like.

This same person recently told me that, over the course of this pursuit, I was the only person they interacted with regarding it who, in their own words, didn’t make them feel like an idiot when they approached me. While I was glad that they had someone like this, I was sad that I was the only one who fit that description.

One thing I have learned over the course of my life is that “genius” is a very relative term: it all depends on who you’re sitting next to. I can name people who make me feel fairly smart just as I can name others who make me feel fairly dumb. I know these people well enough that I can say the latter don’t do this intentionally. Nevertheless, the sentiment keeps my ego in check, which I believe is a good thing.

We all start at the bottom of the totem pole. It benefits you to never forget this and to empathize with those who are going through that journey. Be open to learning from everyone, whether that person is perceived as a master or an apprentice. Nikola Tesla once said, “Our senses enable us to perceive only a minute portion of the outside world.” His words are worth remembering in the context of the limits of our individual knowledge.

Patience

Whether it’s with troublesome technology, difficult people, learning newbies, or even yourself as you go through the process of being a newbie once again to pick up a new skill, you will invariably feel frustrated by one thing or another in the process of being a developer. You have to learn to recognize when frustration is transient, when you can use it as motivation to continue and succeed, and to recognize when it’s a sign that you’ve done all you can do and that you should move on.

Imperfection

There is no silver bullet for anything. This applies as much to one’s technology stack or personal tool belt of choice as to one’s self. There is no state of enlightenment that a developer eventually attains. As cliché as it sounds, being a developer is more about the journey than the destination. The best goal you can set for yourself is to be better at what you do than you were yesterday. Compete with yourself, not with others. Aim to solve problems and be pragmatic, not dogmatic, in how you approach them.

Epilogue

These are things I’ve learned from my own experiences. I state them here realizing that they may be more applicable to me than they are to you. You must form your own opinions and find your own wisdom. I’ve said before what and who make me love what I do. I hope you share in some of that, and in some of what I’ve spoken about in this post. In the end, you must find your own path. Regardless of what that path is, I hope you find the passion shared by myself and those who inspire me and I wish you well in your pursuits.

Sniffing Outgoing HTTP Traffic on an iOS Device

I’m posting this mainly for my own benefit, but hopefully someone else finds this useful. A lot of people have recommended Charles as a debugging HTTP proxy for OS X. It looks like a great piece of software, but does require that you pay for it after 30 days. I was looking for something quick, easy, and free to analyze outgoing HTTP traffic on an iOS device.

Sadly, such options are few and far between, but if you’re willing to install a JDK (which Mavericks handily prompts you to do the first time you try to run a JAR file, and automates much of the installation process), they’re slightly better. I found a free edition of one called Burp Suite and managed to figure out how to get it working, so I’m documenting that here for future reference.

I’m using a Macbook Pro and an iPod Touch to do this, but since Burp Suite is written in Java, it should be possible to do this using any Java-capable device on your LAN and any device running iOS.

On the device with Burp Suite:

  1. Open up a terminal (I use iTerm2), run the ifconfig utility, and note the LAN IP address of the local machine (e.g. 192.168.1.113)
  2. Run the Burp Suite JAR file from a terminal like so: java -jar burpsuite_free_v1.5.jar &
  3. In Burp Suite, click the “Proxy” tab and, within that, click the “Options” tab
  4. Under the “Intercept Client Requests” section, uncheck the checkbox marked “Intercept requests based on the following rules” if you don’t want to modify requests, only view them (because individual intercepted requests are blocked by the proxy until you manually opt to forward them from the “Intercept” tab within the “Proxy” tab)
  5. Likewise, under the “Intercept Server Responses” section, uncheck the checkbox marked “Intercept responses based on the following rules” if you don’t want to modify responses, only view them
  6. Under the “Proxy Listeners” section, select the existing entry in the table and click the “Edit” button
  7. In the “Edit proxy listener” window that appears, next to the “Bind to address” label, select the “Specific address” radio button and, from the drop-down menu next to it, select the LAN IP address of the local machine, then click the “OK” button
  8. Make sure the “Running” checkbox next to the proxy listener is checked, then click to the “History” tab within the “Proxy” tab

On the iOS device:

  1. From the desktop area, click the “Settings” icon
  2. In the “Settings” menu, click the “Wi-Fi” option
  3. In the “Wi-Fi” menu, click the option for your LAN
  4. Scroll to the bottom of the screen, find the “HTTP PROXY” section, and enter the LAN IP and port on which the HTTP proxy is running (8080 by default, you can find it in the proxy listener rule in Burp Suite)
  5. Return to the desktop area, then select the app for which you want to monitor HTTP traffic
  6. Perform some operation that kicks off an HTTP request, then find details on it in the Burp Suite “History” tab

The OOP in PHP Slides Posted

I’ve posted the slides from my “The OOP in PHP” session that I presented at Lone Star PHP 2013. You can find them in the Publications section of this site.

Thoughts on Working Remotely

There’s been a lot of hubbub recently with regard to the recent decision of Yahoo! CEO Marissa Mayer to mandate that all employees, including those currently working remotely, either commute to a corporate office or face termination. This has spurred a lot of speculation in regards to her reasoning behind the decision, from being a less conspicuous form of layoffs to shed expense while saving face with investors to stemming from a more traditional camp of management thought for which productivity requires physical presence in an office. It’s even spurred some accusations of hypocrisy being that Mayer recently paid to have a nursery installed in her office. Be that as it may, I thought I’d take a blog post to share some highlights from my own thoughts on remote working that I’ve gained over the course of doing it for over four years.

Remote working is not for everyone

As much of a public proponent as I may be for remote working, I’ll readily agree that it’s not an ideal arrangement for everyone. Some people need the atmosphere of an office and the presence of managers and coworkers to be productive. These things can have a very real and substantial psychological effect on the motivation and productivity of an individual.

Think about how much time you spend either at work, sleeping, or performing necessary day-to-day tasks like grocery shopping or paying bills. If work doesn’t necessitate that you leave home, you spend a lot more time there and less out in the Real World™. This can be extremely isolating and difficult to tolerate if your employer doesn’t maintain channels of communication that enable you to feel connected to your peers. It also takes a lot of self-discipline to be committed to getting your work done despite there being no one physically looking over your shoulder to ensure that you’re getting the job done.

Remote working has mutual benefits

My commute is the distance from my bed room to my living room. I have time to feed my kids a hot breakfast and put them on the school bus in the morning, then brew a pot of coffee and check my personal e-mail before starting my work day. If I need to, I can step away from my work laptop for a bit in the afternoon to get my kids off the school bus and get them started on their homework or take a short lunch and knock off a bit early to run errands before I pick my kids up from after-school care. Telecommuting and flexible hours enable me to do all these things and thereby significantly reduce my stress level.

I use my own home and internet connection for my work, so I don’t contribute to any needs for equivalent office space or bandwidth in an office. I’m one less car on the roads during the morning and evening rush hours that might be delayed by traffic jams or weather conditions. I’m just a phone call away in an emergency situation. If I’m within reach of my work laptop and an internet connection, that’s as far as I have to walk to provide support. I can communicate in real time via IM, VoIP, Skype, or any number of other tools and mediums.

Remote working has disadvantages

My coworkers need to check their e-mail or be on IM for me to communicate with them; I don’t have the ability to physically track them down or stop by their desk in an office. I may miss out or be the last to hear about casual or in-passing conversations and office news that isn’t formally announced via e-mail. I can’t go out to a local bar for happy hour with my coworkers. I have to open an IM window instead of turning my head to verbally ask a question or make a remark. To at least some degree, I’m out of sight, out of mind, and coworkers must be vigilant to include me in communications, both professional and casual, as much as I must be vigilant to be present and heard. Culture is top-down and has to be maintained both in person and online.

I can’t physically raise my hand to a whiteboard to draw a picture or gesture with my hands. My coworkers can only see my face in photos or video chat. Most of the time, they’re limited to text or my voice and whatever obscure contributions they may make to my ability to communicate. Much of the excitement, disappointment, or general nature of my responses may be lost in translation. I miss out on watercooler conversation and the social element of employment and am forced to find time and opportunity to seek it elsewhere.

Remote working is necessary

The global nature of the job market is only increasing. The state of the US economy is making remote working more of a necessity and less of a privilege. Commutes directly affect the livelihood of those who undertake them in fuel costs, vehicle maintenance, and time commitment. The state of the real estate market and the high variability of cost of living and salary offerings make relocation a difficult or infeasible prospect for many homeowners, which comprise much of the older and more experienced work force.

Limiting hiring to those who are local or are able to relocate significantly diminishes the available talent pool. Companies who dismiss the option of allowing employees to work remotely are forced to hire those who are more convenient rather than those who are best qualified. This leads to a relatively stagnant talent pool as well. Experienced non-local talent is less commonly brought in from the outside, perspectives are limited by locality, and local opportunities for professional development experience less growth. That any of these things need be limited by geography is a limitation that exists entirely in the mind.

Sufficient technology exists for day-to-day operations to carry on remotely in at least close approximation of efficiency to a traditional office space given individuals truly dedicated to that purpose. Any organization that would say they’re “too big” or “culturally incompatible” with remote working is either in trouble or in denial. Either way, they’re doing themselves a disservice that will be illustrated by others like Synacor, GitHub, and Mozilla successfully recruiting the best and the brightest.

Epilogue

Remote working may not  be for every company or employee, but it’s dismissed more often than it should be as a viable employment arrangement. The technological and economical state of the world is only making it more commonplace and will eventually render those who resist it ancient fossils of an industrial era gone by. The age of the knowledge worker has arrived and that knowledge is a commodity that must be sought after regardless of its origin or residence. Any institution that will stand the test of time must follow this principle and eventually globalize or perish.

Why I Love the PHP Community

I had my first contact with the PHP community in late 2005 or early 2006; I can’t remember exactly when it was. Before that point, I’d spent the better part of my life struggling with being bullied and depressed and to some degree still do. If my peers didn’t show me ostracism, they mostly showed me indifference. I often felt like my life had little meaning and that I had no one I could relate to.

Then I found the #phpc channel on the Freenode IRC network. I had the honor and privilege of meeting too many individuals to list here. They didn’t belittle me with ego, much as I might have put some of them on pedestals and perhaps still do. They didn’t admonish me for my lack of knowledge or experience at the time. They didn’t laugh or insult me when I asked questions and showed desire to learn like one might expect in other communities.

They welcomed me. They befriended me. They supported me in my endeavors to become better, as a professional and as a person. They made me feel liked, accepted, and respected. They made me feel like a part of something greater, a community, a family of friends. If everyone could have this, I believe the world would be a much better place.

That’s why I’m so sad when I see public displays that I think might prevent people within that community from sharing my feelings or discourage them from taking part in it. I know what it’s like to feel excluded, marginalized, demoralized, degraded, and discouraged. I don’t wish that on anyone, least of all people I know and respect within this community. I feel that people shouldn’t be singled out or made to feel inferior or objectified. Gender, gender identity, race, creed, ethnicity, sexual orientation — no one should be made to feel like this based on those attributes.

I’m a very sympathetic and empathetic person. I feel things very deeply. I try to consider carefully who I might hurt when I say or do something. I may not always succeed, but I try anyway. In any situation, I do my best to understand where other people are coming from and what their position is. I don’t do this for its own sake, but because I know what it’s like to be hurt and I don’t want to inflict that on another human being. And I especially don’t want it inflicted on others in my beloved community either. And I’m not the only one.

PHP as a language irks me sometimes. Heck,  a coworker of mine started phpsadness.com and it’s difficult to disagree with him on many of the problems that the language has. They don’t stop me from using it, though. I may have come for the technology 11 years ago, but I stayed for the community. And hopefully now, after reading this post, you understand why.

Recipe: Gumbo

Once aspect of my identity that isn’t readily apparent to new acquaintances is that I’m a native of the state of Louisiana. I have red hair from my paternal Irish grandmother. The Welsch and Irish accents of my paternal grandfather and grandmother respectively seem to effectively cancel out the Cajun French accent of my maternal grandparents. I’m a far cry from what someone might expect of a Louisianian if their basis for comparison is comprised of programs like Swamp People. That said, I value my Cajun heritage, particularly its cuisine. A few coworkers of mine expressed an interest in that area, so I thought I’d share a recipe for a local dish: chicken and sausage gumbo.

Ingredients

  • 1 stick of butter
  • 1/2 cup of flour
  • 16 oz of diced onion, bell pepper, and celery or another common variation of the holy trinity
  • 1 12 oz can of amber ale beer
  • 2 32 oz boxes of chicken stock
  • 3 lbs of boneless skinless chicken breasts
  • 1 lb of sausage
  • 2-2 1/2 cups of rice

For the holy trinity mix, I generally use the Creole Seasoning from Guidry’s Fresh Cuts, which contains yellow onion, bell pepper, celery, green onion, parsley, and garlic. Cajun and Creole cuisine share some similarities, such as their common use of variations of the holy trinity, but also differ significantly from each other. Guidry’s is something of a local staple and an easier option than acquiring and cutting the individual vegetables myself, so it’s an instance where I veer a bit from the Cajun recipe for the sake of convenience.

For the amber ale beer, I use Abita Amber Ale, which is produced by the Abita Brewing Company located in Abita Springs about 30 miles north of New Orleans. Their Amber Ale brew has a great flavor that lends itself well to the gumbo.

Finally, for the sausage, I use Savoie’s Mild Pork Sausage.

Directions

  1. Cut the stick of butter into small segments. Place them into a large pot on low-medium heat (on my stove, which has settings of Low, High, and 1 through 9, I use 4 here) until the butter is completely melted.
  2. Use a spatula to stir in the flour. Continue stirring once every 20-30 seconds until the butter-flour mixture, or roux, is the color of milk chocolate. (This will take a while.)
  3. Stir in the holy trinity mix. Continue to stir often until the vegetables soften.
  4. Add the beer. Let the foam settle, then stir until the ingredients are mixed well.
  5. Add the chicken stock, then stir until the ingredients are mixed well.
  6. Increase the heat to medium-high (on my stove, I use 6 or 7) and let the mixture come to a boil.
  7. Carefully slide the chicken breasts into the pot. Let the mixture continue to cook for 45 minutes, stirring occasionally.
  8. Before you reach the 45 minute mark, prepare the rice. I use a microwave rice cooker, which takes about 15 minutes for this much rice.
  9. Also before you reach the 45 minute mark, cut up the sausage.
  10. Once you reach the 45 minute mark, carefully lift the chicken breasts out of the pot, shred them, and replace them into the pot. I just use two forks to do this.
  11. Add the sausage to the pot. (This is done late in the process to prevent the gumbo from getting overly greasy.) Let the gumbo cook for an additional 5 minutes.
  12. Place the rice into bowls and pure the gumbo over the rice. Optionally place the bowls in a freezer for 5 minutes or so to cool them down to eating temperature, stirring them again when you take them out.
  13. Serve and enjoy!
  14. Optional: prior to refrigerating leftovers, mix remaining rice into the gumbo. This will enable the rice to keep in the refrigerator better than it would otherwise and allows for ready-to-heat lunch-size portions.

Gumbo

Speaking at SunshinePHP

Just a quick post to announce that I’m speaking on “Database Testing for Fun and Profit” at the SunshinePHP Conference being held in Miami, Florida on February 8-9. Hope to see you there!

I am speaking at SunshinePHP. February 8th - 9th, 2013 | Miami, Florida

On What to Learn

An aspect that I’ve enjoyed of participating as a mentor in the PHP Mentoring program is the interesting and provocative questions I receive from my apprentices. One such question, and in my opinion a rather important one, came up recently:

“One thing I feel I struggle with is wanting to take on too much. There are so many languages out there, and I would love to learn all of them… How do you balance your time while still staying on top of the game? In your opinion, which languages do you think are the best to focus on?”

This will probably sound cliche,  over-dramatic, overly philosophical, or what have you, but understand that I’m simply stating it as fact to reinforce the point: perhaps our biggest limitation as a species is that we are bound by time. We exist for a very brief period. With every moment that passes, the state of our world is subject to one constant condition: change. A skill you learn today may be obsolete a few years from now. A memory may be with you decades from when it’s first formed, continuing to color your views and experiences.

Some of us — perhaps the best of us — would love nothing more than to have the time and capacity to learn everything that the world has to offer, but that’s not within our physical capabilities. Our only other option is consciously limiting what we learn and what we focus on. It’s regrettable that we must do this, in particular because the acquisition of knowledge is a noble goal, but it is the way of things. To at least some degree, we have to specialize our knowledge.

The question of what to learn is one I’ve pondered before this person ever posed it to me. At a time when I lacked a good answer, I did what I normally do in such situations: I consulted my betters, in this case Dr. Alan Perlis. Dr. Perlis was an American computer scientist with many accomplishments to his name, most notably his pioneering work in programming languages.

In 1982 — the year of my birth, fittingly — Dr. Perlis published a work entitled “Epigrams on Programming” in the monthly newsletter of SIGPLAN, a special interest group of the Association for Computing Machinery focused on programming languages. One quote from this publication stood out to me:

19: A language that doesn’t affect the way you think about programming, is not worth knowing.

I don’t know that I necessarily agree with Dr. Perlis on this point in all cases, but it does provide a rule of thumb of sorts when considering what to invest time and effort in learning. Programming languages aren’t especially different from spoken languages in this respect: learning one Latin-based language may help you to learn others, but learning one that isn’t Latin-based such as Russian or Chinese increases your overall understanding of language.

When I was in college, I took a course on programming languages specifically aimed at increasing our breadth of knowledge about them. We wrote a parser for a subset of ALGOL 60 (a language for which Dr. Perlis was a member of the development team) in SNOBOL, a tokenizer for ML in ML, and an object-oriented rendition of a switch statement in Smalltalk. These aren’t hipster programming languages; the thought that went into their development formed the foundations of modern programming and paved the way for the languages we use today. Each of these proved interesting to study in their own way and fulfilled the goal of the course.

So, to come full circle, here are my reflections reduced to a few epigrams of my own:

  1. Rein in your desire to learn everything while maintaining your desire to continue learning.
  2. Focus your efforts on learning things that contribute to the quality of your understanding and of your craft.
  3. Every once in a while, learn something just because you want to.
  4. Make a point to sporadically have experiences in which learning is not your primary goal.

And one last parting thought: you can find more and better words of wisdom in The Pragmatic Programmer. If you haven’t read it, I highly recommend you make the time to do so.

My best,

Matt

Why I Love Writing Software

“Charlie sees math as beautiful, and he wants everyone else to love it the way he does.”
~ Judd Hirsch playing Alan Eppes in Numb3rs Season 4 Episode 9, “Graphic”

I’ve been using computers since I was five years old. In my early teens, I started writing computer software as a hobby. I took computer science courses in high school and went on to graduate from college with a bachelor’s degree in computer science. All of my jobs have at least involved information technology. Most of them, including the one I have now, have involved writing software.

I’ll turn 31 early next year. I haven’t been doing this as long as some, but I’ve been around the block a few times. In that time, I’ve noticed a few things about how others — muggles, if you will — perceive people who write software. I wanted to talk about those in this post as well as describe what writing software means to me and why I love doing it so much. Whether you do as well or not, please read on.

People tend to think that, in order to be capable of or good at writing software, you have to be a math or science nerd. Truthfully, it certainly doesn’t hurt, but it’s not a necessity. I struggled with math in college. It took me multiple tries to get through most of the math courses with the minimum grade required by my curriculum. As it turns out, I don’t use what I learned in those courses very often when I’m writing software. Given my academic track record, I’m rather grateful for this.

I’ve also found that people don’t view writing software as being a craft or creative pursuit. At its center, writing software is problem-solving. Think about the last time you had to solve any problem, big or small. How did you do it? Was the solution simple or complex? Would it seem unusual or creative to someone else if you explained it? Did you feel a sense of satisfaction when you found the solution? These questions apply to writing software just as they might to anything else, perhaps more so because software can be applied to so many different problems.

Have you ever written something where you carefully arranged information and chose words to make it easy for someone to consume, whether it was a document for professional instruction or a work of fiction? People who write software do this too. In many cases, the software we write can be used by others to build other software. It can be like a tool or the foundation of a house in that respect, except that it can be made available to anyone who wants it by releasing the source code. It’s not unlike releasing artistic works as creative commons and allowing derivative works.

Writing software also has a pedagogical nature to it because the product of writing software is instructions that a computer — and, ideally, a human being — can understand. It’s a way of sharing knowledge in a form that’s usable directly. In fact, software is often written to be usable without having to know how its innards work, much like how you don’t need to know the mechanics of a combustion engine to drive a car. Much like what I’ve felt when teaching or mentoring and having someone form an understanding of something that I’ve communicated to them, there’s a satisfaction in being able to successfully teach a computer to do something useful.

I’ve seen few other hobbies or professions where I can share a problem with someone and a few minutes or hours later have a working solution I can use to solve that problem. And that person can live halfway around the globe from me! The possibility for collaboration on software projects is incredible. People who write software are able to empower themselves and each other to create and empower others by creating things that make their lives easier. As pervasive as technology has become in our society, the ability to exercise this power can be both useful and enjoyable.

If this post reads in a bit of a distracted way, it’s because the reasons why I love writing software are many, diverse, and wonderfully complex and nuanced. I think it has a beauty all its own and that’s something I want to share with others. Hopefully, what I’ve said here has given you some insight or, if you write software too, it’s reminded you of why it’s a passion we share. I’d love to hear your thoughts in the comments. Thanks for reading.

7php Interview

This post is a bit belated, but 7php interviewed me last month about how I got started with PHP, my work on the PHP Master book, the Phergie project, my advice to beginning PHP developers, and other assorted topics. Feel free to give it a look.