I was at a party my Filipino family friends threw for my twenty-first birthday last weekendwhen one of the younger kids asked me how I became such a young successful professional. The term “successful” is debatable, I would say, but I nevertheless decided to write down some of the lessons I’ve learned along the way in hopes that someone else will at least find them a bit helpful. Thus, if you are interested in the random musings and observations of a fresh grad software engineer, read on. In any case, I hope you at least laugh, learn something, or even just remember what it was like on your first job in the industry. Enjoy.
If you are a young girl in tech, realize that you will be different, accept that, but don’t expect others to change for you. Joining a new team of men who don’t look, talk, or act like you can really feel alienating at first. Fear not, in a few months, your hard work and coding skills will earn their respect, and you’ll be part of their crowd before you know it. For now, try establishing conversations by asking them about their family, weekend plans, or how long they’ve been working at the company – people love to talk about themselves. Frankly, unless the people you work with are total jerks, they’ll include you in the conversation if you make an effort to join.
Also here is a quick tip when you get really nervous about meetings, pair programming sessions, etc. When I would almost freeze during my first few code reviews, I just try to remember that these tough-looking guys have daughters and sisters just about my age. I might be a total wack-o, but thinking of that really helped calm my nerves.
Be aware of the imposter syndrome and use it to your advantage.
I was complaining to one of my best friends who has about one million masters and PhDs (he must know what he’s talking about, eh?) about how I’m scared to do this, and I don’t know how to do that, and other girly froufrou worries that I should be ashamed about. Fortunately, he really served it to me by saying that really, just having signs of the imposter syndrome is in fact, a very good sign showing that one is a high performer, versus otherwise being one of those arguably cocky people who don’t know that they don’t know anything (see the reverse, the Dunning-Kruger effect).
I’m just going to quote from this article from
Forbes because it says it all:
“In fact,
- the higher the standards you like to set for yourself,
- the more you are used to being an expert
- the more self critical and type-A you are naturally inclined to be,
the higher the chance that you will experience this ‘Imposter Syndrome’ ….
And the bigger the leap you’re trying to make, the worse your Imposter Syndrome symptoms are likely to be.”
So the next time you start freaking out thinking you are a total fraud and don’t belong, congratulate yourself. It means you are doing something important, something outside of your comfort zone, and are surrounded by very talented people. That is exactly where you want to be — embrace that fact and instead of losing confidence over it, use it to your advantage! Being surrounded by very talented people is the prime setting for learning a lot, almost effortlessly! (
See tip number 3 on Sukindher Singh Cassidy’s advice. She’s a former Google exec and founder of Joyus.) On that note, I actually sit behind the head of North America Policy, and just hearing his phone calls and conversations has really taught me a lot about managing people and handling difficult conversations. Having feelings of inadequacy is also a good time to question what you think are your weak points — and improve on them. This alone will build your confidence, productively.
Learning a massive, enterprise code base will be a steep learning curve, so you can relax that, yes, you are not a total idiot.
Where I work, new engineers have to work in support for a few months, fixing customer-reported and internally-found bugs. It is a great way to get familiar with a lot of the code base, but it can be overwhelming at first. Just remember that managers don’t really expect you to be contributing significantly for about six months, so use that time to really study the code base without any pressure. Also, please remember that you are new and although you are obviously brilliant, do not criticize code when you’ve been there two weeks, and the guy who wrote it has been working there for years (He’s brilliant too and probably has a good reason why he did it the way he did, which is not obvious to you, Newbie). A little humility goes a long way.
A little positivity goes the distance as well. We all are working on bugs and tough problems — groaning in your cubicle and complaining on how much you hate your issue is not going to help. Having a positive, can-do attitude helped me get along extremely well with a software architect who fought for me to be able to join a new project faster than normal.
Also, take notes of everything; make OneNote your new best friend. Setting up new development environments for the first time can be challenging, and you won’t remember everything the next time you have to do it by yourself. In the future, you can even share your notes with the new guy, and he’ll be forever grateful. When I was new, another awesome girl developer sent me her notes, and that Word document has saved me countless hours! Another developer set up a wiki page of all the errors he encountered when he was setting up his environment for the first time, and I can’t even count how many times I’ve used that as a reference.
The newer smart guys are a gold mine.
No really, this deserves its own heading and paragraph. You want to find the really smart guy who is hasn’t been there for that long either and buddy up. He will still remember what it was like to be new, so he will be more willing to help. He will also tell you easier ways to do things that the other guys who have been there for forever won’t even think about.
You will have to take charge of your own learning.
I hope you are as lucky as I am. We have assigned Career Counselors whom we meet with every other week. Not only does mine help me set professional goals, he holds me accountable too. Now that I’ve seen how having actual learning goals helped me improve tremendously in a short amount of time, I regret a lot of my undergrad years. How I wish I took a more proactive approach to my learning! I can’t even remember how many times I’ve expressed my desire to join an open source project or how many times I’ve said that I want to try being a project manager (with technical chops) someday — yet I didn’t do anything about it. Meanwhile, two years have passed, and I still haven’t done anything. Nada.
I think we as people don’t do things, not because we are lazy per se, but just because we are too busy. Between classes, internships, and personal lives, if we don’t carve the time to learn about the things we want to learn, we will never do them. So starting this week, I’ve made a goal of reading one book per week from Joel Spolsky’s software management
reading list. I actually read somewhere that if you read one book per month, you are ahead of everyone else already.
Just because you’re in tech doesn’t mean you shouldn’t write or communicate your ideas well.
Solving problems with smart people rely on a lot of communication, written and verbal, on a white board, in code reviews, in email. You’ll talk to a lot of QA and clients too; you’re not just always going to be in a basement coding algorithms. Being an engineer is no excuse for letting your communication skills slip. Remember that software development in itself is an art of communication: you are telling a computer what you want it to do.
Again, I will quote that which I cannot say any better.
“I’ve found that some of the best developers of all are English majors. They’ll often graduate with no programming experience at all, and certainly without a clue about the difference between DRAM and EPROM.
But they can write. That’s the art of conveying information concisely and clearly. Software development and writing are both the art of knowing what you’re going to do, and then lucidly expressing your ideas.
The worst developers, regardless of background, fail due to their inability to be clear. Their thoughts and code tend to ramble rather than zero-in on the goal…
Too many engineering-trained developers have a total disregard for stylistic issues in programming. Anything goes. Firmware is the most expensive thing in the universe, so it makes sense to craft it carefully and in accordance with a standard style guide. Make sure it clearly communicates its intent. This is where the English majors shine; they’ve spent 4 years learning everything there is to know about styles and communication. “
“In the same vein, programmers who pay attention to how they construct written language also tend to pay a lot more attention to how they code. You see, at its core, code is prose. Great programmers are more than just code monkeys; according to Stanford programming legend Donald Knuth they are “essayists who work with traditional aesthetic and literary forms.” The point: programming should be easily understood by real human beings — not just computers.”
In programming, we all know that one little detail can make a big difference, especially when you are working on bugs and still trying to learn the code base. I’ve worked on quite a few customer reported bugs that seemed so complicated, and one little detail that I remembered and mentioned to another more experienced engineer made it turn out that it actually, wasn’t a bug at all. My point there is that in programming, it is all in the details. Plus, if you’re smart enough to breeze through recursion and Calculus 3, you are smart enough to know when to use a period or how to express your thoughts clearly.
Frances just graduated with a degree in Computer Science with specialization in Software Engineering. She works as a Software Developer for Accenture Software. She also contributes to The Levo League, Women 2.0, and STEMinist. A proud geek girl, she’s sure she is the only one who can’t play video games. Follow her random musings at @FranAdvincula.
Tweet This Post
To calculate and communicate ROI, I follow these 5 steps:
After a successful career in the software industry, Karen Catlin now focuses on developing powerful women leaders. She draws from her experience as an executive to coach individuals, lead workshops, and advise companies on hiring and retaining female talent. Karen also writes “Use Your Inside Voice,” a blog about the intersection of parenting and leadership.
Angie Chang is Editor-in-Chief and Co-Founder of 
At times I look back and think that I’ve done well for myself, while experiencing many failed attempts to get what I want and be where I desired. In short, I have learned many lessons the hard way.
