Impostor!

So I work as a software dev, which you may have gleaned, you smarty pants, you. I started late in life, had the wrong degree and was never that much of a nerd to begin with. Through study, some luck and a lot of reading, I landed a job, then another, then another and another yet again. I’ve been getting paid to code for a little over two years now. But you know what? I still feel like I’m one bad piece of code away from someone ‘finding me out.’

The first three months of my first job as a dev, I felt like I might get fired everyday. It was awful. I wondered if they had made a mistake, were the just filling a quota by having me, was there literally no one else that applied? I felt pretty useless, made more bugs than I fixed and one particularly bad program I wrote in my first year actually cost the company around $10,000. Fuck.

Around year one, I felt like I belonged. I started having the answers to difficult questions, creating user stories and offering my opinion during code reviews. I even created a few full stack applications on my own that affected hundreds of stores across the nation. Then… I left. I worked at a couple bootcamps during my first job which allowed me to sharpen my skills but then I took the big plunge and joined a start-up as dev #1. Double fuck.

Here I am, two years in as a dev, at 34 and with 3 kids and still feel like a kid playing dress up. Part of me knows that I’ve been here before and this too shall pass, another part of me wonders why I and others feel like this in the first place. Working in a super technical environment can be tough: there are clear benchmarks for your success and your product, for better or worse, is on display and open to criticism. Developers are also a smart bunch. I work with an MIT grad, a former Googler and a guy that wrote a fucking testing library that we and thousands of others use. The amount of big brains in the room can be a little daunting at times.

If you’re starting off your first developer job or in my case your second and you’re feeling like me: I can tell you, after talking with a lot of engineers from non-traditional backgrounds, that the feeling will subside after a while and when you begin making regular contributions you’ll feel more at one with the team. I can also say that in the last two years, despite all the cringe-worthy things I’ve said in interviews, on the job or making small talk over code that showed my lack of knowledge and noob-ness, not once was I ever laughed out of the room. Turns out devs aren’t such a bad bunch.

I was surprised to see just how far up the rungs impostor syndrome can ascend. I spoke with the VP of Technology at my last job, a man who I respected as one of the smartest guys in any room. He told me how he felt like the dumb kid, even now, 25 years into his role when he was around other CEOs. My lead developer, a stone-faced prodigy who seemed to be able to tackle any problem, told me he almost quit during his first six months on the job because he felt he would never figure it out. The more devs I’ve spoken with, the more variations of this story I get. Triple fuck.

I guess the bad news is, that feeling of imposterism might be yours for a while. The good news is, you’re in good company.

Why You No Like CSS?

Ok, I’ll admit, I’m not the biggest fan of CSS. Well, maybe I’m just not a fan of ME writing CSS. Many of the devs I’ve met over the years seem to echo this sentiment as well. But why? CSS is what makes our sites look not like Craigslist, it engages users and sets the tone and feel of our application. It does so much for us and yet here we are complaining about it. What a pack of ungrateful fucks. For Shame.

I mean, I do get it. If you’re not on the design team you may not be doing that much CSS or maybe, like too many of us, you’re more concerned with logic and functionality of your site to care about the style. `I’ll let Bob handle that part of the app,` you say. Fuckin’ Bob. I have the sneaking suspicion that most of us who don’t like working with CSS just don’t know it that well.

I had the opportunity to sit down with one of the members on my team and walk through the re-design of one our pages for our web app. I expected it to be a curse filled 8 hours of trying to figure out why this div didn’t float near that div but this guy was actually looking forward to it. Sicko. We (he) finished the re-design fairly quickly and I was amazed at his command of CSS. Our site looked better and I learned a lot along the way.

What I really learned from watching this master at work was how rudimentary my knowledge of CSS was. I wasn’t making use of CSS’s native answer to Bootstrap, FlexBox, wasn’t taking advantage of pseudo-selectors to implement logic that we had unnecessarily delegated to Javascript and hadn’t used SASS very much up to this point.

Some Takeaways:

  • Use percentages/em over fixed px for things like width, or font. This way you won’t need to create more media queries than necessary and your content will be more proportional to the browser window.
  • Just use SASS already. Jesus, how did I miss this train? SASS let’s you nest CSS rules in components so you can have clear separations of CSS logic (and a lot more). Here lemme show you:

  • .myBigDiv{
    font: 'Roboto';
    .btn{
    background-color:'green';
    &:hover{
    background-color: lighten(20%);
    }
    }
    p{
    text-transform: capitalize;
    }
    }

    Now I have rules that apply to all my buttons and paragraph tags that are in my div with a class of big div. I even put a nice hover effect on my btn that will make it appear lighter when hovered over.

  • Is there logic like capitalizing an input that you’re using JS for or truncating a string? Maybe CSS can just do that for you? We were doing just that and replaced that logic with CSS properties text-transform and text-overflow:ellipsis, respectively.
  • Let your framework do the heavy lifting! There were many places on our page that was reinventing what Bootstrap is already capable of like adding padding, floating elements or the like. Check the docs… can this be done without me actually coding it?
  • My advice, to myself and perhaps to you if this applies, is to stop running from CSS! Aside from Craiglist, users expect to see some visually engaging UI. Embrace the CSS, love the CSS.

    Books For Nerds

    I began writing this blog with the assumption that you, like me, are either a self-taught programmer or new to the world of code… or maybe just a fan of off-kilter, profanity-laced blabbing. Like you (or not like you) I do not have a CS degree. I went to college, studied liberal arts, alcohol and drugs. After bumbling about and doing a number of different jobs over a decade, I found my calling in writing code.

    I remember the first year I was paid in actual US monies to write turrible code; I was happy when the code ran, left few comments and relied heavily on the work of more senior programmers to help get me out of logically tough spots. I gradually got better at writing code and understanding how the internet works. Through days of coding for work and nights and weekends working on side projects, I figured I was pretty damn good at my job.

    But, coding only took me so far. I felt like I missed out on the CS fundamentals that no amount of coding could replace, so I put the one skill my liberal arts degree gave to me use: reading. A lot. I scoured blogs like this one (with notably less profanity) for suggestions and read my way to a better understanding of CS fundamentals and problem solving skills.

    Here’s a few books I recommend if you’re looking to round out your knowledge as a software developer:

    Programming Pearls. This is an older book but will introduce you to many of the complex problems you will likely see and gives you a glimpse of how a master programmer tackles them.

    Clean Code. This book reinforced some of the principles of writing code I learned on the job and introduced me to many techniques I hadn’t considered. A good read with many, many examples.

    The Complete Software Developer’s Career Guide. It’s a hell of a read at around 1000 pages but nicely broken up into chapters that deal with many aspects of a career as a dev. The advice is great and whether you’re looking to get a raise or a first job, it has some great insight.

    Data Structures and Algorithms with Javascript. There are many books that tackle this subject but I chose this one because I’m most familiar with JS and if you’re self-taught or out of a bootcamp, you likely are too. This book will take you through the most common data structures and goes into more depth than many of the online courses I’ve seen.

    There around a fuck-ton of books out there that cover the world of software and I gave you like, 4. Some of these books may tickle your fancy, or maybe you’ll think they suck. If you got any gems you recommend, please drop ’em on me.

    My StartUp Life

    So for the last two years, I worked at a mid-sized corporation on a small agile team creating software. It was a great experience and as my first job in software, I learned a ton. You’d think in my advanced age, and with a family that I would welcome the kind of stability a traditional business would bring… and I did. But something inside me wanted to go out there to really ‘prove’ myself at another company, to learn a different way of doing things, to take a risk. So here I am three weeks into my new job as software engineer at a 7 person startup as the only non-remote engineer and the one with the least experience. Reading that last sentence aloud now makes me wonder if I’m as crazy as it makes me sound.

    At my old job, it must have been a good two months before I pushed out any real code and I didn’t see it in production for another few months after that. There were meetings with higher-ups, a project manager, a department VP and other support staff to help us tread the agile process. Today marks the end of my third week at my start-up and I’ve pushed about three features into our production branch. The fuck.

    Of course I expected the start-up life to be fast paced but when your in the throes of it, it’s amazing how much autonomy you really get working at a small company and how quickly change takes place. The relaxed dress code, open schedule and the fact that most of the team is remote create a casual atmosphere but the break neck pace at which the code changes and new feature requests are added is already dizzying, especially as the guy in the room that knows the least.

    Part of me misses the hand-holding and gentle on-boarding that I was so used to, but when your company is too small to play a full court basketball game, you’re gonna have to get up to speed on your own in many ways, whether it be learning the business, navigating the code, setting up your tools or choosing a health plan.

    For my first job, I’m incredibly happy to have worked for a larger company. They gave my the opportunity to dip my toe into the water of software development before having me swim a few laps in the channel. Conversely, about now I feel like I’m treading water in the ocean, wondering what the hell that thing is bumping against my leg… in a good way though. I think.

    If you’re interested in jumping into the deep end and working in the startup scene, I recommend checking out Angel List.

    Learn That Language/Framework Faster!

    The one thing I like more than coding and fancy tacos is dropping the kind of knowledge you can’t get in a college. Every Sunday, I put on my teaching hat and work a with a small class of students at a part time web development bootcamp. I also work as a full time web dev so Sunday’s class is usually a breeze for me… for the students, not so much.

    HTML and CSS are usually the fun weeks. ‘Oh cool! Some shit appeared on a screen.’ Neato. Bootstrap adds another layer of complexity and then things get a little hairy… the moment I introduce variables, booleans and conditional statements in javascript, things go south in a hurry. That word ‘var’ just scares people. Because our class only meets once a week, I encourage students to do a lot studying on their own. I’ll admit, it can be a little frustrating watching students struggle through a basic for loop for the 30th time. Why don’t they just get it? Now, in all fairness, I work with javascript (and other languages) 8 hours a day, 5 days a week, so it’s easy for me to forget just how difficult it is learning new things. Well, now I find myself in their shoes…

    You see, two weeks ago I got a job offer at a startup (of course… fuck, I am a stereotypical Bay Area dev now). Cool motherfucking beans! Now, comes the hard part: I’ve been using AngularJS, C# and .Net for the last two years and Node, React and Python at home. Well, this company uses EmberJS, Ruby on Rails and Postgres. Shit. Here I am on day 12 after I heard the news and I feel comfortable enough with Ember after studying a bit after work each day to hack together a crappy front end app. Two years ago I also didn’t know .Net, C#, or AngularJS. I’ve found a pretty decent method to learning things (well enough) to be dangerous in a relatively short amount of time. Here it is:

    Mix Up Your Learning Methods

    Some people need books, some need videos, and others might need a paint-by-numbers style tutorial. I need all of these and more. I will use at least three mediums to learn a new language/framework. I will scour the net for blogs, short books and of course the docs on said topic and see what I can glean. My goal here is to get some basic information and best practices and to know what I’m dealing with. I’lll usually buy a cheap Udemy course after that (usually around $10) and work my way through about half of it. The reason I rarely finish these courses is because they become more of a crutch than anything around the midway point (more on that later). Lastly, I might find a meetup, join a slack channel or listen to podcasts about this new language/framework and check out some open source work to see some good examples of it in action.

    Tutorial != Understanding

    I used to complete a tutorial and read a book about a language and think I’d be an expert as soon as I was done. When I needed to learn C#, I bought a book then completed a 19 hour tutorial the week before work at my new job began! I went into work that Monday at my new job and had absolutely no fucking clue how to write C#. I knew what a static void, namespace, class and other trivial shit was but that didn’t help me write production level code. While I encourage reading and tutorials to my students, I always warn them about relying too much on books or tutorials. How may times have you finished a tutorial which is essentially coding by numbers (they type then you follow) and then when you go to fire up a new project, armed with your newfound skills, you are utterly lost? I’ve been there.

    Build Shit

    Ok, you’ve read about this new tech and have a general understanding of how it works and some of the gotchas. Check! You completed a few video tutorials or some todo app. Double motherfucking check! Sweet. Now here’s the part where you get lost in the weeds: think of something very simple that is reasonable to build over a week. Great. Now build that shit. You will be stuck, you will be frustrated and you will be googling furiously, perhaps cursing out the inventor of said language. “Why isn’t this more like here?!” You should be cycling back to steps 1 and 2 during this stage to supplement your barebones skills and by the end you will likely have a crappy app that shouldn’t see the light of day.

    Congrats, you now know more than 92% of all people who complete a Udemy course or pick up one of those ‘Dummies’ books.

    Are You a Front End Dev Afraid of JS?

    These days, front-end dev can cover a lot of ground: at one company it could be the guy who does web content updates and tweaks the HTML and CSS on the public facing site, while at the start up next door it could be the girl who doesn’t do as much UI as she does complex client side javascript code to manipulate and traverse the massive amount of data being retrieved from the backend, writing unit tests and doing Tuesday night deployments… either way, the mistake I see too many devs make who are looking for front-end work make(I was guilty as well) is they think they can avoid the ‘hard’ parts of javascript.

    What are the hard parts, you ask? Sure, things like recursion, scoping, hoisting, closures and bumbling your way through ‘this’ are some of the conceptually difficult parts of JS but I’m talking about the ability to solve problems.

    You see, this is the part of web development that’s not so easy to teach: how to solve shit. You can memorize a whole bob damn book on MVC, Routing with Express and spout off some little known facts about how `setState` works in React, and that’s great, don’t get me wrong, but can you figure out how to remove duplicate objects from an array of objects?

    Well, can you? It’s easy to say ‘Yea I could figure that shit out,’ then, lulled into a false sense of JS mastery you come across a problem like this at an interview, or likely, on the job, think back to this article and punch yourself in your quinoa eating face for not attempting it.

    Many new devs, especially those on the front-end of things try to forgo solving these seemingly trivial problems using JS either out of fear or they don’t see the value. I’ve been there. I tried my hardest to avoid JS beyond DOM manipulation until I was forced to do so.

    As a FE dev, you’ll probably be calling lots of APIs to populate a page with some data. That data will likely be an array of JSON (or XML if you’re unlucky) and you probably won’t need all of that data or you’ll need to manipulate that funky object your neck-bearded backend team created.

    One of the tools I use that has improved my JS and logical skills the most has been codewars. I believe the first problem I solved took around 3 hours or more. Still today, I may toy around with a problem for a day or two (or a whole fucking week) until I get it. While approaching many of these problems can seems overwhelming, I can guarantee that the path you take to either solve or fail at it will lead you to greatly improve your JS skills and more importantly, your ability to just solve stuff.

    The best part of CodeWars is that you get to see the clever attempts other devs have made and get a glimpse at some really stellar code. For you savvy code challenge aficionados who ask why I didn’t give leetcode or hackerrank a shout out is simply because their IDE wasn’t as friendly for writing JS code (IMO).

    Now go back and figure that shit out!

    Web Dev Self Study Guide

    Wow, let me blow the cobwebs off this blog before I get down to business. In the last couple months I began a part-time job as an instructor/developer at a local bootcamp and added another human to my family and unfortunately this blog was left in park but then something happened…

    A few weeks ago, a friend of mine, looking for a bootcamp, sat in on one of my classes and was interested in joining but the price tag and uncertainty of the job market upon graduation were major concerns. As a member of one of my favorite coder’s, Laurence Bradford’s Facebook group, Newbie Coder Warehouse, I noticed this same issue was preventing many other people from joining bootcamps or online programs. Now, it may not be in my best interest to tell you, or rather write you, nah, let’s just go with tell you it sounds better… anyways, what I’m trying to tell you is that you don’t NEED a bootcamp to get a job.

    Here’s what bootcamps give you that self-study won’t: motivation, peer pressure, access to a developer who will have the answers to all those gotcha questions that may take you hours to find online, and a clear and concise path to web dev super stardom. Now, the motivation and peer pressure mainly come from the high price tag most camps charge: you tell your friends you’re shelling out upwards of 15 grand for a camp and quitting your job, then you damn well better finish that assignment on CSS media queries on a Tuesday night. For many people, keeping their interest and engagement in learning is not an intrinsic process and they need an external influence to keep them on the straight and narrow… that’s not a bad thing, it just may mean you will benefit more from a traditional class enviro (I just shortened environment, let’s try and make this a thing… enviro!) than the free wheeling self study path.

    Here is the email I wrote to her outlining what I think is necessary, in the Bay Area, in 2017 to become an entry level developer; there are many places where I encouraged her to write me with any questions or further explanation on what to study and that offer is open to you the reader as well (my email is at the bottom of the page and in the contact section)

    ***
    I thought about what I do at work and what I see as a typical day for a junior developer and what skills are necessary to join a team as a contributing member. Here’s a rough outline of what I think you’ll need:
    HTML & CSS:
    Take codecademy’s HTML and CSS course as well as their bootstrap course. Replicate two web pages: Google’s home page and a much more difficult page like the front page of air bnb or the home page of apple (not the functionality) just the look.
    You should also be using web development tools in chrome like inspecting elements on the page and feel comfortable adjusting the css from the browser.
    You should have a good concept of how to create a basic web page, ids, classes and how to use images, add links, etc.
    This could take 2-3 weeks and I would watch some videos or read about what you can do with chrome browser tools, css box property, positioning elements, inline vs block style display.
    More CSS:
    CSS is tricky and you’ll really need to get a good hang on it before moving forward. Google ‘PSD’ (photoshop design) and pick a couple PSD’s of web pages/sites and replicate them using html and css. These projects can be used in your portfolio which you will need later.
    Github:
    Get a github and push some code to your repos every few days and at least once a week. You should feel comfortable creating new repos, and pushing code to them through the command line. Try to pull some other projects from people as well. Every recruiter will look at your github so keep it up to date. Git is perhaps the least friendly language you’ll come across so watch a video or reach out if it’s difficult to get started doing that.
    Bootstrap and Responsive Design:
    Understand Bootstrap’s grid system and make use of their components like dropdown menus, navigation menus, etc. Start using bootstrap for every site you create because nearly every company is using bootstrap or something like it. Responsive design is basically what people use to make sure their website sizes down properly when looking at it on different devices. Codecademy has a great course on Bootstrap you should take. When it comes to media queries, reach out to me after you’ve done some Googling on the subject and we can go over how to implement them.
    Make a Site:
    Google free bootstrap templates, get a template, and make a site for a friend or a local business. This will be your first “real” project that shows people that you can do developer stuff. BTW, using a template is not frowned upon, in real life you’ll be using a template or working with a large code base and updating features so this is more like what you’ll likely be doing than creating something from scratch.
    JQuery:
    Use codecademy’s course on Jquery to get down the basics. Learn how to make elements disappear, fadein, fadeout and change their css through button clicks. Add some jquery to your previous projects.
    JS:
    Once, again, use codecademy to get the basics down and maybe even buy this book. Do everything you can do with jquery with plain javascript. Make a one page quiz that tells user’s their score after completion. A random quote generator. Google fizz pop challenge and do that. Create a simple login system. Make a site that iterates over an array of objects with car info, including pics and display it on a page. Go on codewars and frustrate yourself with some challenges as well. You should be able to iterate, do for each loops, shift, pop and push into arrays and create objects.
    More JS:
    Learn about object constructors, object literal notation and prototypal inheritance. These are all fancy ways of constructing and replicating objects in JS.
    AJAX:
    Make http requests using Jquery’s ajax method. Search the web for API’s (todd motto has a great list) and use these API’s to retrieve information from a server and display it on a web page on a button click or allow users to enter a search term that will retrieve info. I can walk you through all this when the time comes. AJAX and using web services is how many companies accesses their databases so getting a good grip on ajax and calling web services is key to getting a job.
    Databases:
    MongoDB is pretty hot but so is Firebase. Firebase takes only a few minutes to set up and stores your data in JSON format (just like mongodb) through an API call. It’s easy to use and will give you a nice intro to databases and hosting data outside your local machine. I’d create a simple login using Firebase and a page where users can post and retrieve messages or whatever…
    Node:
    Download nodejs and express through your command line and learn how to set up a server on your machine to host your files. There are about a million tutorials on this. Node allows you to write server side code in javascript like creating apis, accessing databases and other server stuff we can go over.
    JS Framework:
    Learn React! React is javascript but just a different way of writing it and it’s super hot in the bay area so get down the basics. By this point you should be able to pick up a framework and tinker around with it and find online resources to help you. That’s basically how you’ll pick up whatever framework is in style if you decide to get a full time dev job.
    The most important thing is to code for a little bit everyday and always google stuff you’re curious about or don’t know. Create a codepen account and make fun things for POCs (proof of concept). You don’t need to know everything on this list, in fact I would begin applying once you can create a basic web page, make ajax calls and feel comfortable using javascript in a functional way.
    You will learn more on your first job than any amount of studying and things change constantly so the best asset is a desire to learn and pick things up quickly. React won’t be here in five years, maybe less, but javascript will so feel comfortable with it!
    As you go down this list, you should have many questions lol so always feel free to reach out and send me a link to your projects on your github account if you’d like me to check them out. If you have time, go to meetups and meet with other coders as it will allow you to see how others work and different ways of achieving the same goal.
    ***
    I hope you found this email I wrote to a friend helpful and if you think I should add anything to this list, or have questions as you embark upon your path to web dev hot shot, feel free to email me: hotdevdude@aol.com brianjenney83@gmail.com