Don’t be afraid to “fail”

This is a guest post from Cierra Nease. Enjoy.

Dear new developer,

“Failures” as a new developer are plenty — but you might be asking, why is “failures” in quotes? To fail something is dependent upon one’s perspective. The only true failure is to quit working towards success. Every failure brings a small success in that you learn what the right answer is not. How can you problem solve without a way of marking off solutions that do not work? A failure is simply a solution that didn’t work at that specific time.

We can all talk about how learning and growth come from having failures, but it’s hard to remember that when you feel like you are a failure. Failures do not inherently make the person a failure, and it can be hard to make that distinction in the moment. Sometimes we need someone else to remind us of this.

I’ve had a lot of people in life reiterate this concept to me. The most recent person was a fellow developer named Mike on the Denver light rail. It’s funny what will happen when people participate in communicating and interacting with each other, but that is for another blog post entirely. For now, let’s go back to Mike. Mike overheard me talking to another passenger about being in a bootcamp. When I finished my conversation, he handed me a card and said he’d love to answer any questions I have about becoming a developer. I elaborated on some of my bootcamp experience, which happens to be full of failures.

Mike expressed his number one piece of advice for any developer, telling me: “whatever you do, don’t be afraid to fail.” We started talking about this in depth, and it really resonated with me for the rest of the evening. As a new developer, you really only see senior developers’ successes. Each developer goes through their own learning process which does include failures.

The failures that lead to success don’t stop when you become a “better” developer. If you are looking for a point when you quit failing as a developer, then you are looking for the wrong thing. The more you fail, the more you learn. The more you learn, the more you grow. The more you grow, the better the developer you become.

As a newer developer, I look forward to all of the opportunities to learn, grow, and accept my failures as the wrong solution instead of accepting them as a personal characteristic.

Sincerely,

Cierra

Cierra Nease is currently studying software development. She blogs at Cierra Codes 101.

Three Mantras to Live By

This is a guest post from Dave Mayer. Enjoy.

Dear New Dev-

After 22 years of ‘production level’ experience in the real world, I’m writing to share three mantras that have led to more happiness and more success for us.

To be clear, these are DAILY mantras. Not weekly, not monthly, not annually. Daily.

They are:

  • Surround yourself with people smarter than you
  • Build community and give without expecting anything in return
  • Listen to your gut, without exception.

Surround yourself every-damn-day with people who are smarter than you

You’ll never be, nor should you, be the smartest person in the room. Confucius reportedly wrote ‘if you are the smartest person in the room, you’re in the wrong room’. Regardless of who wrote those words, they couldn’t be more true. Since high school, I’ve always known that I was smart, but I was also clear that I was not the best at everything and that everyone had something to help me learn or to help me become a better student or a better human.

I’m not suggesting you surround yourself with jerks with a ton of pretense who can’t stop talking about themselves and how smart they are, I’m suggesting that you learn to say ‘I don’t know’, ‘wow, that’s cool, tell me more’, and ‘yes, I could use some help’. Knowing that you will never have all the answers, that it’s okay to ask for help, and having an insatiable curiosity about engineering, life, music and anything that is important to you will get you far in life.

Build community and give without expecting anything in return

In 2006, going into the ‘Great Recession’ we sat in the back of the room at the Boulder-Denver New Tech Meetup and listened to Brad Feld talk about bringing people together and building community (in whatever area and subject that matters to you) with no expectation of anything in return. This idea of #GivingFirst was revolutionary to us thirteen years ago, and it’s been a life-changer for us. It’s a super simple yet elegant idea of walking into a room and asking how you can help someone solve their biggest challenges rather than where-do-they-work-or-what-kind-of-car-do-they-drive. We wrote a detailed article about this topic for CTO Lunches Magazine on page 29- give it a read. It’s truly been life-changing to help others and embrace that as a BUSINESS philosophy, not just a life philosophy. It will all come back to you, you just don’t know how or when, and that’s OK.

Listen to your gut, every day without exception

It sounds simple, but not everyone does it. Your intuition is always right, yet folks second-guess themselves, rethink things and question their own motivations. That’s all healthy, and yes, you should ‘sleep on it’, whatever ‘it’ is. Space gives clarity. In large decisions, I ALWAYS take at least 24 hours to think on what the right answer is for me, and to listen to my gut. It’s NEVER failed me and it will never fail you. I promise.

I hope you will consider even one of these three mantras. You won’t be disappointed.

– Dave

Dave Mayer is a long time community building advocate, and by day he’s CEO of Technical Integrity, a boutique recruiting firm focused on building diverse executive and technical teams for startups in Colorado and beyond.

Don’t try to change the tabbing / bracing style

This is a guest post from Andrew Rondeau. Enjoy.

Dear New Developer,

Don’t show up an a new job and immediately try to change the tabbing and/or bracing style. This is especially important if the codebase you work on has a very consistent style that all of the other developers follow.

Why? Tabbing and bracing styles are really a matter of personal preference. What’s important is that the codebase is readable, and keeping a consistent tabbing and bracing style is more important than having your favorite style. Furthermore, because tabbing and bracing styles are really a matter of personal preference, arguing with the more senior developers about this topic is a waste of everyones’ time. The senior developers, or your manager, will probably assume that you have poor time management skills, or that you get obsessed with details that don’t matter.

And, yes: An interesting discussion can be had over the merits of tabs versus spaces, or the merits of braces before or after the newline. The problem is that some people really get irrationally attached to whichever style they are used to. These discussions don’t fix bugs or deliver features that the business needs to survive; thus, don’t waste time and stick with whatever tabbing and bracing style your codebase uses.

When is it important to discuss tabs versus spaces, or bracing styles, as a new developer? When a codebase has an inconsistent style, especially if it doesn’t match a team’s style guide! Politely point out to your manager, or lead, that there is a lot of inconsistent use of tabs and/or braces; and suggest a tool that will automatically reformat the code. Perhaps suggest a style that a well-known open-source project uses, or a well-known style guide published by Microsoft or Apple. At that point, it’s your manager or lead’s discretion if your team will adopt a new style.

If your team does agree to change the tabbing and/or bracing style, don’t do it gradually. Why? Again, a consistent style is more important than being able to write code with your preferred tabbing or bracing style. Inconsistent code is harder to read, and confuses people about what the established style really is. It also tempts people to stick with their preferred style, instead of whatever the team agreed to. Instead, use an automated tool to reformat the code.

— Andrew

Andrew is the desktop client architect for Syncplicity, a file synchronization product. Here’s his LinkedIn profile.

Learn a Little Network Engineering

This is a guest blog post from Allan Wintersieck. Enjoy.

Dear new developer,

I realize that just trying to learn basic programming principles can feel daunting enough, but if I may, I’d recommend adding one more task to your list: learn a little bit about network engineering.

Networking underpins everything web and app developers do, since almost every web app communicates from the frontend to the backend regularly. Most developers understand the basics of making API calls and how data flows over the internet, but taking a small dive deeper will help you debug issues for years to come.

The goal is to build your underlying knowledge so that when you encounter related issues in the future, you understand enough about how it all works to intelligently tackle the problem. For example: the reason everyone complains about CORS (Cross-Origin Resource Sharing) being confusing is because it doesn’t make sense without first understanding the basic principles of networking and security.

A quick list to get you started:

  1. Read up on the basics of routing. No need to dive into how the protocols work, but understand why it’s set up this way and how internet traffic gets to where it needs to go.
  2. Read the basics of DNS, and understand how a DNS request is resolved.
  3. Read a brief rundown of the OSI model. Focus on understanding one or two examples of things you’ve dealt with in the past that exist at each layer.
  4. Review the difference between TCP/IP and HTTP, and why they exist at different layers in the model.
  5. Read up on the basics of what a “proxy” is.

An overall analogy that I find helpful: networking is like sending mail via the postal service.

  • Routing is the process of putting mail in your mailbox, having a postal worker pick it up, and it eventually reaching its destination.
  • DNS is the process of looking up someone’s mailing address so you can send them mail.
  • The OSI model is a fancy name for making it clear that there’s a lot of details the postal service takes care of for us. Most people understand how addresses and mailboxes work (let’s call that the equivalent to the Application layer), but don’t really understand all the internal details of how the postal service gets your mail to its destination. All those details are the first 6 layers of the model.

With that background knowledge in place, tackle some of these additional questions to lead you to more learning:

  • How do CDNs (Content Delivery Networks) work?
  • What’s the difference between “regular” HTTP and WebSockets?
  • How does SSL (HTTPS vs. HTTP) work, at a high level?
  • What can nginx be used for?

And as a last exercise, sketch out a complete picture of a work app or side project: what DNS calls get made, what servers are involved, are there any proxies, what protocols are in use, what OSI layer those protocols exist on, etc.

I promise that spending the first few years of my career as a network engineer only slightly biases me towards learning this stuff.

Sincerely,
Allan Wintersieck

Allan Wintersieck is the CTO and co-founder of Devetry, a software consultancy in Denver that provides strategic partnership for software architecture and engineering.

 

Balance Questions With “Banging Your Head”

This is a guest blog post from Don Abrams, lightly edited. Enjoy.

Dear new developer,

When starting out, the hard part is balancing two things:

  • Asking questions
  • Banging your head against the wall

Additionally, as a new developer you’ll likely be encountering something for the first time: a codebase that is really really large. Like large enough no one knows all of it. You’ll want to learn how to navigate the codebase ASAP. Every place is different. If you can checkout all the code and get the product running in less than a day, you’re at a world-class shop. If it’s more than a week, I’m sorry.

After you learn to navigate the code, my recommendation is then to learn and copy the patterns that other team members use. So your questions should mostly be “how did someone solve this before?” or “hey, have you seen anything like this before?” If you look at the code they referenced and still have questions, then bring it back up ASAP.

If someone offers to pair, DO IT! Tip on pairing as a junior: be the keyboard and basically have them tell you what to do. You’ll learn how they think about the codebase and learn to navigate it better. You’ll feel stupid when they tell you “just” to do something, but those are the things you need to know. (“just XXX” signals that XXX is complex thing that you’ll take for granted soon– documenting those will really help the next junior).

I also recommend reading a LOT of code.Then, as you get a better command of the codebase and team patterns (3-6 months), you can start asking questions like “why did someone solve this before this way?”

That’s when it gets fun.

Sincerely,

Don Abrams

Don Abrams has over 10 years of software development experience and recently moved to France.

It will turn out mostly fine… if you have the passion

This is a guest post from Jenn Chu. Enjoy.

‘Passion is one great force that unleashes creativity, because if you’re passionate about something, then you’re more willing to take risks’
~Yo-Yo Ma

Dear new developer,

I’ve always taken the quote above to heart… fast-shooting myself into the named camp of ‘Career Switchers` when talking about entry into the world of development. I’ve majored in Mechanical Engineer, spent 10 years in the Oil Industry, and just the last year and a half, really immersed myself into development.

I started at a Bootcamp part-time, got the certificate, quit my job, moved to a new city, worked as a Bootcamp TA and then finally landed my first job as an Associate Developer. It definitely wasn’t an easy journey, but I was passionate about this new life decision and I became obsessed. If not for the passion that led to a slight obsession, it would have been 10x harder to get to where I am.

For a new developer starting out, I’d love to tell you that it will turn out just fine… it mostly does… if you are passionate and have the drive. Learning new technology is not the only thing you should do to give you the edge. You must also go out, meet people, network, make projects, breathe… and then repeat. Learn the technology by finding out how it works more so than just watching tutorials. Meet the community and find coding and project buddies. Make projects for ideas to improve your life, or the life of others.

What I found most helpful in this whole process is having a mentor. Find a like-minded individual that is genuine and genuinely wants to be invested in your new journey. There is so much experience and knowledge that can be shared between both individuals, it truly is a beneficial experience for all involved.

Again, never stop learning, doing, networking and above all, doing what you do, what you are passionate about. The light at the end of the tunnel starts to get brighter and brighter with each passing day, have faith and take the risks! Life is too short otherwise.

– Jenn

Jenn Chu is a software Developer passionate about good design and building simple solutions that will enhance the end user’s experience. She is most excited to bring the diverse community together through collaboration, communication, and connections.

‘You get what you give’

This is a guest post from Rylan Bowers. Enjoy.

Dear New Developer,

‘You get what you give’ isn’t just a late ’90s catchy pop song set in a late ’90s mall that gives me late ’90s cringe (and nostalgia, but those go hand-in-hand, eh?). It’s also a great way to approach your career! This is something core to the tech scene I’ve adopted in Boulder, Colorado as codified by Techstars with their Give First rule in their Code of Conduct. Their other rules are great ones to build your career around, too.

I have found that giving provides many benefits to the giver:

  1. Offering to help engenders a greater sense of observation and consideration of others’ needs and feelings. This is something we all can work on, given our reputation as social introverts.
  2. It feels good to help others with no strings attached.
  3. If you want to attach (small) strings for your own motivation, you increase how others view you in a positive light.
  4. You may/likely will find rewarding hobbies, coding interests, or other intrinsic rewards without much effort.
  5. You become less arrogant.
  6. You help build your community in a positive way, no matter how small the give is.
  7. People are quicker to recommend you for a job or position if you ever fall on harder times.
  8. It improves your own sense of self-worth and confidence.
  9. You make more friends outside of work.
  10. Did I mention that it just feels good?

My one caveat: There are always people who will take advantage, do try to be open-minded and kind, but watch out for takers, they will burn you out! Thankfully, they are few and far between.

Another great example of this is Jason Cole’s “Year of Giving Dangerously”. I must add that this way of living is out of reach for you as a new developer, but something to keep in mind for over the course of your career. Give in small ways until you can give in bigger ways!

Also, be aware that being seen as only a taker is not a good thing. See my caveat above and think back on any time in your life that you’ve ran into one. Maybe someone who always wanted to copy your answers or homework, but never contributed? Or those group projects where you felt like you were doing all the work? Don’t be a taker.

Volunteer in your community. Be the good you want to see in the world.

– Rylan

Rylan Bowers is a developer, co-organizer of Boulder Startup Week and the Boulder Ruby Meetup, and all around good guy. Follow him on Twitter.