Hello, My name is Ashley McNamara, I am a developer advocate at Rackspace, but I wasn’t always. In my previous life, I was a photographer.
Let me preface this by saying that I do not consider myself a great developer, but i’ve always wanted to become a better developer.
So, today, I am going to talk about the things i’ve learned along the way.
I’ll talk a little about myself and who I was before I was a “developer”, I’ll drop some knowledge that I wish I had when I was starting.
Remember, this isn’t a one size fits all solution.
This isn’t about the basics. Of course, improving your development skills is necessary.
Learning about things like, Clean Code, Great Design, Test-Driven Development, Agile Methodologies, Test Coverage, Complexity Design Patterns, Reactive Programming… etc.. is important, but that’s not what the focus is today. *psst.. Write those things down and google them later.
All great developers have, ‘daddy issues’ - I’m kidding.
My dad has been a huge influence in my life, he’s the reason for most of my personality traits, the good ones and the bad ones - my stubborness, my temper, the fact that I curse like a sailor, but he was also the reason I have a love for technology.
My Dad was an old school network engineer and was on the team responsible for building the first networks for Nato. I’ve had a computer for as long as I can remember, long before most people had computers in their homes, but the best part was that my dad was constantly upgrading his system, leaving me the spare parts, which I would put to use building my own system. It wasn’t long before our house was the neighborhood gaming house and I wasn’t mad about it.
Remember, being a geek in the 80’s wasn’t cool. Now you can spend $30 bucks on oversized glasses at urban outfitters, but back then it was rough...
I would have been so trendy by today’s standards?
God, look at her... She has no friends.
No, really, I had no friends.
So, I reinvented myself to be more socially acceptable.
I was never complimented on my ability to build computers, my vast knowledge of starwars, or quake, but I was often complimented on my creativity. Girls didn’t do computers.
The fact that I could hand draw a ninja turtle or was an ace at the rule of thirds was clearly more important and more… socially acceptable.
So I did what was expected of me. I became an artist… A photographer.
But even as a photographer, I was still building.
With any business you have to find your target market and for me, that was photographers.
Back in the day you had to know how to use a camera to get great pictures, but now in the digital age, you don’t, so I capitalized. I had enough clients to show that I could run a successful business, but most of my income was from business coaching, making and selling photoshop actions, plugins, and presets… I needed to market myself, so I learned SEO, I built a website, and a blog. It wasn’t real dev work, but it was a start and I didn’t know it at the time, but those projects were building the foundation for what would come next.
I started posting free photoshop tutorials and quickly became a thought leader in the photography community.
Now it’s 1999, the tech bubble is about to burst and I hadn’t strayed too far from the tech industry.
My now ex-husband… I know, this just got awkward, but I have to give credit where credit is due and he’s very much part of my journey. Anyways, he was also a network engineer and I found myself attending 3-4 tech conferences a year.
Most other tech wives would be paired up and do ‘wife activities’, but I was different, looked forward to attending the show. I would ‘borrow’ someone’s badge and sneak into sessions or scan the show floor for punny t-shirts… I’d fill my bag booth swag ( stress balls, usb keys, and hardware flyers) and hang out with the other geeks at the after parties. I loved the community and I felt like I belonged.
As the years passed, my ex started pivoting his career into open source and I found myself part of a brand new community. This community was different. It was bigger, more opinionated, and community wasn’t just the conference scene, it was something they depended on.. Now, here I am, part of two communities.
Community is your most important resource. I know many of you know that already, but how seriously do you take it?
I didn’t suck at photography, but I found myself burnt out and looking for something else. I was already contributing to a number of open source projects and had decided to open source my photoshop actions and plugins. I wrote a blog post titled: “Why the photography industry sucks” and it got a fair amount of attention and it was in that blog post where I shared my desire to become a developer. I wanted to make more meaning ful contributions to the open source community.
In fairness, I had a lot of support.
In March 2012 I was accepted to a prestigious (all womens) coding academy. I was bright eyed, bushy tailed, and determined.. I mean, I was already writing simple programs when I started the program. Hell! I had even built a website - how hard could it be?
I was not prepared.
This was a note I wrote to myself on week one.. Some people are natural developers. They instinctually break things down into smaller, more consumable problems. I was a, “Whole picture” sort of gal. All I saw were large walls of code and I just couldn’t wrap my brain around the logical breakdown. My learning style is a combination of visual and tactical which means that ideas, concepts, data need to be associated with images and techniques for me to fully grasp them. This isn’t ideal for learning software development, but it’s not impossible.
People usually focus on writing code, but reading code is just as important.
Coding style, design patterns, naming conventions, formatting, algorithms, data structures, and logging are things that we were left to figure out on our own.
But I kept at it. I was working 18-20 hours a day. I would spend 8-5 at the academy and then go to a meet-up or to my mentors house and work into the night.
After 15 weeks and countless hours coding I was finally graduating.
They printed us business cards and told us all that we were now software developers, but I didn’t feel like one. I still felt green. Remember, I grew up in this industry. I know developers and I knew I wasn’t one. Not yet at least. I was told that I had imposters syndrome.
There is a blog post on this very topic. I didn’t have imposters syndrome and expressing a reasonable amount of doubt and concern about a situation that is slightly outside your comfort zone is normal, responsible behavior. My totally reasonable amount of self-confidence is not a syndrome and I wasn’t going to sit there and act like I was more than I was.
I had a competitive advantage. I grew up in the industry and I already had a community. Far before I enrolled in the coding academy I was doing things like contributing to open source projects. I didn’t realize how much community mattered.
Until I graduated and didn’t have a job.
When you go to a bootcamp you’re not really paying for an education, you’re paying for a community.
I left the academy a little deflated. I had amazing mentors, a project in my github account, but no job. Why? Because the journey to developer doesn’t end with bootcamp graduation, in fact, i could have skipped the bootcamp all together. If I could go back in time, I would do these twelve things.
A great developer isn’t just great at writing code, they also know what good architecture looks like, they write clean code, they automate testing, they use continuous integration, they know about design patterns and principles, … software development is about a lot more than just writing code, particularly when we are talking about application code rather than frameworks, libraries and components.
I’ve noticed that sometimes developers have negative feelings about architecture because software architects are the guys in white button up shirts and ties, they tell you what to do, but they don’t really know what they are talking about and lots of languages abstract away from what is happening at the system level, and that abstraction is useful because it allows developers to be more productive much of the time. But when you hit a roadblock, a really nasty bug, and need a deeper understanding of what's happening under the hood, well it's a useful skill to be able to debug a process and look at the system calls and really see how a piece of code is interacting with the rest of the system
When I was just beginning programming, there were a lot of things that I really didn't understand about computers themselves. File systems, networking, and how things are kept in memory are three obvious examples. This meant that I would not necessarily understand the goals of some of the programming constructs I was being presented with.
As a developer, chances are you’ll spend a good deal of time working with a fancy IDE or code editor. However, also knowing how to get things done at the command line could occasionally make your life easier.
Know the shell like you know how to breath. Tools like find, diff, vi/vim.. How to write little scripts right on the command line to find the file that needs to change right fuckiing now because production is broken and Tim who fat fingered a URL in said unknown file is on vacation.
A good chunk of your time as a developer will involve tracking down bugs so learn to use your debugger! “Take that extra day or two to configure it. When you don't see the expected result, just debug it: set breakpoints, step through your code, and esp. 3rd party code. It will save you days of frustration, and even better, you will learn things about coding you can only learn by reading someone else's code.
Contributing to open source projects are a great learning opportunity. You’ll collaborate with people all over the world and you’ll learn a lot about technical topics, but also about collaboration and communication.
In the beginning I was afraid to contribute.
I found it terrifying that people would be looking at my code! Judging it? Knowing that I wasn’t all that great? It sounded like a nightmare.
I thought I was going to hold people back or even worse, be mocked. The truth is that there aren’t enough people making meaningful contributions to open source projects and any help you can give it welcome, the community is warm and mentors are plenty. Your contributions are resume builders. I’ve seen people get jobs by contributing to open source.
If your code is bad, it won’t be merged, it’s all about learning. (Example)
I was lucky, I had 3 really smart and supportive mentors.
Finding someone who can pair program with you, check your github, and introduce you to industry thought leaders is important and it’s not as hard to find a mentor as you may think. All you really have to do it ask, but remember, it’s not their job to teach you how to be a developer, it’s your mentors job to guide you.
Once you’ve identified your mentor’s don’t be afraid to ask for help. If you can't figure it out yourself by re-intuiting the API or debugging, ask for help. Just because you think you've written a masterpiece doesn't mean it isn't crap or
can't be better.. Often just stating the problem aloud enables a eureka moment.
There are lots of other parties involved in a Software Development project.
The actual software development is just one part of the overall process. People who are experts in other domains contribute to the software development project.
So how do you collaborate with all these parties … from a software developers point of view?
Despite the stereotypical notion of programmers working alone with their headphones on, developers still have to
work other people. Collaboration between the different groups is changing.
I hear a lot of buzzwords nowadays but what a lot of them have in common is that they include a much closer collaboration between different groups of people.
Devops is a good example for this. At the core it promotes a very close collaboration between software developers and operations people.
Presentation skills are very useful for developers: The ability to summarize complex concepts and explain them to people with differing skill levels is invaluable.
Everyone knows that technology changes quickly these days. That applies not only to our beloved consumer goods, but also to the underlying systems, languages, and tools that programmers use to do their jobs. New coders should be prepared for, and stay ahead of, change. Right now, I'm of the mind that you should plan to learn essentially brand new technology stack every ~ 4 years.
Good foundational knowledge is always applicable, but the tools and tech you'll use every day will be completely different every 4 years.
If you’re not sensing a theme, then you’re not listening. Community matters. There is a meet up every night, in almost any language you fancy, meeting new people in the community is vital. Hackathons are also something worth doing. Always be building. Participate on social media blah blah blah (More notes here)
You can learn a lot at these events and you meet a lot of interesting people. Make use of opportunities, attend events and maybe even contribute actively to such events.
Various groups of non-experts are often involved software projects These are actually not non-experts, but just experts in other domains than yours Having some basic knowledge about these other domains help in the communication and collaboration You do not need to be an expert, but it helps to know some things, particularly what drives the people, how they think, what they care about and what they value.
Knowledge about the business domain is particularly important.
In the end, this is the area where you as a developer are trying to provide value.
Understanding the customer/client is the key to building great products.
Actually understanding what the client or customer is talking about. Terms, words, expressions, …
Understanding what the client/customer is interested in and cares about.
Understanding how what you are doing creates value for the customer.
Formalizing the (often informal) concepts of the customer.
In the end you have to explain this to the computer...
Be willing to give back to the community and keep the cycle going. Blogging error codes, experiences, cool code.. Etc…
I mentor at 2 co-working spaces, 1 coding academy, I am on the board of 23 user groups, (more notes here)
A great developer needs excellent technical skills. But that is not enough. It’s also about making those skills available to other people The value of a developer lies within what he or she knows and can do, but also how well the team and the client can make use of this knowledge and skills This “API layer” is already very important today and I believe that it will be even more important in the future
