![\"Paper](\"http:\/\/breanneboland.com\/wp-content\/uploads\/2017\/01\/mexico-town-garlands.png\")
<\/p>\n<\/p>\n
I hit my one-year anniversary as a software engineer in October. It has been, professionally, one of the harder, stranger years of my life, but the challenges generally were exactly what I hoped they would be: complicated, but with clear questions, and answers that were a pleasure to seek. That said, there are a few things I wish I could whisper to my past self, either right when I was starting this job, just as I was starting Hackbright, or a couple of years ago when I wrote my first lines of Python. Here\u2019s a bit of advice to my past self, to anyone who\u2019s considering this journey, and to anyone who\u2019s still fairly new and would like a little reassurance.<\/span><\/p>\n If you want to learn programming, you <\/span>do<\/span><\/i> need to just pick a project and proceed. I really disliked this advice when I first heard it, because I am all about context, and I couldn\u2019t imagine picking an appropriate challenge without knowing the limits and possibilities out there. And that’s a legitimate concern – it’s crucial to pick the right-sized problem, so far as complexity and the number of tools it will require, if you’re going to learn without getting so frustrated that you quit prematurely. Even so, it\u2019s those raw edges, that unpredictable stuff, that gives you the real learning, that can be the most educational (and most satisfying) to wrap your brain around.<\/span><\/p>\n My real, substantial learning on this job began when I was put on a project, which didn’t happen immediately after I was hired. I had learned things before then, self-studying along in the office, but it lived strictly within the realm of the hypothetical (something I consider likelier a limitation of my own beginner state than anything else). Learning within the context of a project can be kind of like memorizing a poem by hearing every fifth word, and out of order and occasionally\u00a0in a different language to boot. However, what you do learn will be practical and actionable, and – perhaps most valuable of all – will provide the context around what happened and what you need to do. And eventually, you\u2019ll know a lot of it – and be able to intuit or sleuth out the rest. <\/span><\/p>\n My suggestion to you:<\/strong> it\u2019s annoying how much it\u2019s true, but I\u2019d suggest just giving in (and finding a good advisor for picking and shaping your project, if you can). Find a practical problem in your own life and decide a way to start addressing it. If you get stuck, it\u2019s a big, generous internet out there, and some of the people in it will even have right answers.\u00a0<\/span><\/p>\n Bonus\u00a0suggestion:<\/strong> consider making a command line utility. It has a delightfully low barrier to entry and gives you a great chance to make something useful to you without worrying about\u00a0deploying or front-end work. If you’re a Python kid like me, start by looking at argparse<\/a> and then let your imagination run away with you.\u00a0<\/span><\/p>\n Bonus bonus suggestion:\u00a0<\/strong>many programming communities now have Slack networks that are open to the public, if you request access. If you know you’re interested in a particular language and want someone to ask questions to, see if there’s an active Slack channel for your area of interest. The availability of DMs and the more regulated, curated nature of most Slack communities can make them friendlier\u00a0to beginners.<\/p>\n Computer science\u2019s history is relatively short, but it\u2019s some dense archeology, if you\u2019re trying to wrap your head around even the most essential central stuff. Some people get to be immersed in it for four years before they’re thrust into the workplace; the rest of us get to pick up on useful commonality\u00a0when we start playing with our third programming language. (Though people like Gayle Laakmann MacDowell have said that this is far from an insurmountable hindrance<\/a>.) The good thing is that each new skill\u00a0you learn will require slightly less origination and effort and will build slightly more on things you\u2019ve already learned.<\/span><\/p>\n However, this growing\u00a0knowledge will never reach one hundred percent, regardless of your background. If you plan on staying in this field, you have to\u00a0learn to love at least a little constant disorientation. If you aren\u2019t confused on the regular in your first couple of years in this field, you\u2019re not trying hard enough. <\/span><\/p>\n My suggestion to you:<\/strong> learn to love feeling like your feet aren’t quite firmly planted beneath you, because it means you\u2019re in the learning space. Disorientation means you\u2019re surrounded entirely by new things to learn. Eat it up.<\/span><\/p>\n My company is largely remote four days a week, and I was, for a time, the only engineer in our central office. This meant that, if I had a problem and my manager wasn\u2019t available, I had to go into a public Slack channel to seek help. This eased in time, mostly as I got to know\u00a0my coworkers better. But until I got to that point, every question I asked felt like broadcasting my ignorance to the company, who only knew me as the inquisitive little Slack avatar.\u00a0HEY LOOK AT ME HERE’S THE THING I DON’T KNOW OF THE HOUR.<\/em><\/span><\/p>\n That is, until I stopped caring because I understood that no one else cares. And beyond that, it’s as true here as in any other field that the best time to ask basic-ass questions is toward the beginning, when they naturally occur, before you start eroding the foundation you\u2019re trying to build.\u00a0<\/span><\/p>\n My suggestion to you:<\/strong> breathe deep and get over it – or pretend to until it\u2019s true. Admitting you don\u2019t know something is a vital part of being good at this job, because there\u2019s no room to bullshit. Any fudging you do will be revealed later, and most likely at a really annoying (and embarrassing) time. \u00a0<\/span><\/p>\n Expertise can sometimes be demonstrated by knowing who wrote what language, what the most vital book is about a subject, or the history of the specific design decisions and needs that went into\u00a0a framework. But this is surface trivia, and what\u2019s most important (to me, so far) is context and the experience that provides it. It\u2019s still the thing I crave most often, when I find myself in those disorienting moments where I don’t know the answer and am not even entirely certain of the right question. <\/span><\/p>\n It can be extra frustrating because I don\u2019t just want to know how something works. I also want to know the situations where considering that thing as a solution on a project\u00a0is appropriate, what would inform that recommendation, and what you heard about its past releases and future plans\u00a0that might make everything terrible in six months.<\/span><\/p>\n I felt this basically constantly at the beginning and now, fourteen months in, I still feel this way pretty often. I choose to view it as still finding this field incredibly interesting. I can\u2019t imagine what being bored or plateauing would look like in this job because there is always, always more stuff. And, after a while, you’ll have experienced enough of it that you’ll know better how to navigate the next big thing.\u00a0<\/span><\/p>\n My suggestion to you:<\/strong> hang in there, mostly. And just be willing to try things, volunteer for new projects, and get all of the experience you can – within reason. <\/span><\/p>\n I have, in the past, annoyed lesser bosses by asking <\/span>why<\/span><\/i>. When I asked, I wasn\u2019t questioning their judgment – or not usually, anyway. What I needed was to understand what went into a given\u00a0decision, so that I could\u00a0make my own decisions to\u00a0support it appropriately. (Yes, it does make sense that I have user research in my background too.)<\/span><\/p>\n This quality is really useful in this job – in fact, in a well-functioning environment, I\u2019d call it essential. It\u2019s particularly so when you do consulting for clients, as my company does. Sometimes we serve them better not by doing exactly as they request but by asking <\/span>why<\/span><\/i> enough (and politely enough) to find out what it is they really want. From there, good work actually gets done.<\/span><\/p>\n My suggestion to you:<\/strong> your beginner enthusiasm and curiosity are valuable tools. When you don\u2019t take anything for granted, you can notice things more seasoned engineers don\u2019t. If something isn\u2019t clear, ask about it (even if only privately to your boss) until it becomes clear. <\/span><\/p>\n Early last year, I was doing some experimenting with AWS on my own at work, going between the command line and the web UI to launch instances, tailor and tweak them, and get used to the interaction between different aspects of the tool. But for a few weeks at the very beginning, things <\/span>just didn\u2019t work right<\/span><\/i>. I\u2019d follow a tutorial, enter a command, and – what even the hell? Trying to spin up an instance would fail. Security groups wouldn\u2019t work right. And, worse still, I was so new and the failures were inconsistent enough that I couldn\u2019t deduce any logic from what was happening. I was failing and didn\u2019t feel like I was learning from it, one of the worst feelings. I rarely have reason to wonder if maybe I\u2019ve been secretly stupid all along, but in that handful of weeks, I\u2019d stop sometimes and wonder if engineering was finding some sad new quality of mine that had been hiding throughout my career.<\/span><\/p>\n Then another senior engineer got hired and had a little time before being put on a client. He found that our AWS account was old enough that it worked differently than more recently created ones do. He made a new account. Suddenly, tutorials made sense, and my results were predictable – including my errors. I was so relieved I had to stop and stare into space for a few minutes to absorb it all. AWS and I are friends now, despite our rocky start, but I would never have figured this out on my own.<\/span><\/p>\n My suggestion to you:<\/strong> sometimes the problem is between keyboard and chair, sure. But sometimes it is <\/span>not<\/span><\/i>. Ask questions, pair with someone, and make sure that someone who knows more than you witnesses your sticky moments sometimes. It\u2019s ego-deflating, but it\u2019s better than spending days or weeks flailing in some swamp that isn\u2019t of your own making. <\/span><\/p>\n If you have even a semi-active sense of curiosity, you can spend endless amounts of time reading docs, essays, StackOverflow speculation, comments, comics, reviews by the competition, helpful blog posts, amusingly bitchy blog posts, and so many other things that may be very useful, completely useless, or – worst of all – approximately 29 percent useful. It\u2019s that last one that can eat your afternoon. If you aren’t aware of this particular hazard, you can lose an hour or four much more easily than you might have ever suspected.<\/span><\/p>\n My suggestion to you:<\/strong> timebox that shit. And if you have access to someone more experienced than you, work out a relationship where you can come to them pretty regularly for reality checks and course corrections before you sail yourself deep into the ocean of chatty, chatty internet people. It’s ok to ask a more senior person to rule out some obvious stuff before you dig into researching your problem.<\/span><\/p>\n (And if the docs are shit, should you really be using the thing it’s documenting\u00a0at all?)<\/p>\n I realized recently (thanks to talking with one of my bosses; see the previous section), that I\u2019d developed a habit I\u2019ve nicknamed narrative research. I\u2019d come to believe that the most efficient way to work through problems was to try to match my problem to someone else\u2019s phrasing, find their solution on this or that third-party site, try to get that solution working to fix my problem, and <\/span>then<\/span><\/i> work backward to find out why what I had done worked, to learn a larger lesson from there.<\/span><\/p>\n Perhaps you\u2019re already seeing the problem here.<\/span><\/p>\n If the tool you\u2019re using requires the backassward methodology of someone in a completely different context than you to get it to work, it may be time to examine if you\u2019re using the right tool – or, perhaps more likely, if you\u2019re doing it right at all. You can stir your coffee with a screwdriver if you really want to, but there are better ways to use it. If you have a problem to solve, research just enough to find what library or whatever it is you need to use – and then use its own documentation<\/em>. Don\u2019t work off-label unless you really need to. Probably check with someone more experienced, if you really think this is a good idea.<\/span><\/p>\n My suggestion to you:<\/strong> there be dragons in Stack Overflow sometimes. Stay with primary resources as much as you can.<\/span><\/p>\n I most often need one between three and four pm, just to perk my brain up to get through the rest of my day. A single Americano is a great way for me to address this. Recently, I messed up and overcaffeinated myself via the rookie mistake of using a bigger glass than usual for my cold brew. I spent the afternoon sweaty, with racing thoughts. Not a good look.<\/span><\/p>\n This is general life advice too, but I\u2019ve found it more critical in this job than any other. It may seem surface, and maybe it is surface, but having your biological needs in check will let you do better at this. <\/span><\/p>\n My suggestion to you:<\/strong> know thyself. <\/span><\/p>\n This is especially important for me and my consulting colleagues who have a vested interest in quality billable hours, but: if you\u2019re sick, be sick. Don\u2019t soldier through. (And not just because of the obvious part about not being a disease vector. Seriously, stay off my BART if you’re ailing\u00a0and have sick time to use.) If you feel like shit, you\u2019re not going to be able to brain, and this work requires a functional brain more than any other job I\u2019ve had. The others could be difficult too (especially the UX consulting gig I had just before I went to engineering school), but it\u2019s just\u2026 different. Pack a snack, sleep enough, and pay attention when you\u2019re sick. <\/span><\/p>\n My suggestion to you:<\/strong> be an adult and be honest with yourself. Sleep enough, eat enough, and stay home with pho from Seamless if you\u2019re under the weather. Treat yourself like you’re parenting a toddler – you know,\u00a0honest assessments<\/em>. Sometimes you just need a snack; sometimes you need to stay the hell in bed.<\/span><\/p>\n This is an industry riddled with social fuckery, and even people who found it worthwhile to stick it out usually have at least a couple really vile stories of colleagues and managers acting like total assholes. I work in a magical unicorner of the industry that\u2019s largely free of that, but – get this – I still get points just for being housebroken and friendly enough that it’s pleasant to share space with me. It still seems to be considered remarkable in this industry (though it\u2019s a requirement to work at my company). Can you treat a troublesome team with human decency? Can you be polite and keep it together even when you\u2019re having a bad feeling and not getting your way? Do you have a regular life, and can you make nice chit-chat about it without it being a big thing? Congratulations: you have an important skill.<\/span><\/p>\n Beyond that, social stuff in tech is just different than it is in other industries. I\u2019ve always been lucky enough to have coworkers I wanted to be friends with too, but there\u2019s a certain all-banding-together kind of feeling in tech that I haven\u2019t seen anywhere else. In some companies, it\u2019s a natural side effect of putting a bunch of 22-to-29-year-olds with a shared predilection for alcohol in the same space for 60-plus hours a week. But even then, it has a function – when stuff gets hard, that empathy and caring and shared knowledge comes together, and everything functions better. <\/span><\/p>\n My suggestion to you:<\/strong> be cool, honey bunny<\/a>. And, even if you have limited social energy (I certainly do), try to conserve some of it to spend time with your coworkers once every week or two. A lot of people are lovely, and the stuff about being a good member of a team is easier if you\u2019ve taken a real interest in the people around you.<\/span><\/p>\n There you go, new engineer. There you go, Breanne of a year or two ago. And here are a few more resources\u00a0that I’ve found really useful in the last year. I didn’t even write all of them myself.<\/span><\/p>\n1.\u00a0<\/span>Everything I heard about learning this is true (or: no, really, just pick a project).<\/h2>\n
2. Learning is a skill. Learning<\/span> this<\/span><\/i> is a different skill.<\/span><\/h2>\n
3.\u00a0<\/span>Any dregs of self-consciousness and admitting ignorance will either go out the window fast – or you will remain bad at this.<\/span><\/h2>\n
4.\u00a0<\/span>Useful experience is less about exhaustive knowledge and more about navigating new situations and tech.<\/span><\/h2>\n
5.\u00a0<\/span>My sense of curiosity is a valuable job qualification. <\/span><\/h2>\n
6.\u00a0<\/span>Sometimes the tool <\/span>is<\/span><\/i> broken. Not you.<\/span><\/h2>\n
7.\u00a0<\/span>Timing is everything. <\/span><\/h2>\n
8.\u00a0<\/span>Unless the docs are shit, trust the docs.<\/span><\/h2>\n
9.\u00a0<\/span>If you\u2019re a person who does the caffeine thing, get your coffee game down.<\/span><\/h2>\n
10. Don\u2019t be a hero when you\u2019re sick.<\/span><\/h2>\n
11. And, finally: decency counts.<\/span><\/h2>\n
\n