I was having a conversation with some younger colleagues today about early-career development. I thought I’d jot down some tips based on what has worked for me. The following list is incomplete.
If you feel overwhelmed, know that 1) it’s the code that’s the problem, not you. 2) you will get through it. No matter how much I learn, I haven’t stopped feeling like an idiot when I’m facing a new codebase or tool. But I’ve gone around the loop from total bewilderment to total mastery enough times that I’m sort of used to it now. It’s still painful, but I know it’s temporary.
Have the highest standards you can imagine.
In my life as an architect, I found that the single thing which inhibits young professionals, new students most severely, is their acceptance of standards that are too low. If I ask a student whether her design is as good as Chartres, she often smiles tolerantly at me as if to say, “Of course not, that isn’t what I am trying to do. . . . I could never do that.”
Then, I express my disagreement, and tell her: “That standard must be our standard. If you are going to be a builder, no other standard is worthwhile. That is what I expect of myself in my own buildings, and it is what I expect of my students.” Gradually, I show the students that they have a right to ask this of themselves, and must ask this of themselves. Once that level of standard is in their minds, they will be able to figure out, for themselves, how to do better, how to make something that is as profound as that.
Don’t compare yourself to other people, except maybe to get inspired by what they’re doing. Focus on doing better than you were yesterday.
Know that the ideal is unachievable. Try to achieve it anyway. Be kind to yourself and others.
Do the best you can and let go of the results. Yes, there will be schedule pressure and other demands placed on you. But you can’t control what comes out of the software development “machine”: all you can control is what you put into it. There is nothing you can do to go faster except to calmly do your best at every moment, letting the results be what they’ll be. If you can do that, what is there to worry about?
A few years ago, a friend of mine was between jobs and set aside two months to work on a side project. He told me his goal was to work on it 40 hours a week for those two months. I asked “why isn’t your goal to ship a product?” His response was very interesting. “I can’t control whether I end up with anything worth shipping. All I can control is whether I’m at my desk doing the work.” I think he had the right idea.
Distrust authority. Don’t accept “the way we’ve always done it here.” The bar for software quality is unbelievably low. “Industry standard” should be an insult. You can almost certainly come up with something better.
Read books and blogs. Unfortunately, this has gotten a lot harder because every software-related search term on Google is now stuffed with AI-generated spam that never gets beyond extremely superficial, watered-down summaries. But here, I made a reading list.
Don’t stress about learning all of your company’s weird internal systems. If the interface to a typical programming language or database contains about 🤏 that much complexity, a typical application contains about 🫸___________________🫷that much. The “foundational” type of knowledge is going to be much more useful when you change jobs. Prioritize your learning efforts accordingly.
Learn Ruby. Read your Poignant Guide. This is an oddly specific one, but Ruby showed me that programming could feel different. Simple. Eloquent. Heartwrenchingly beautiful. And fun!
And that’s about it! Maybe you’ll find this useful, or maybe not. Feel free to send me your questions and comments.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.