Forem: Joshua Graham

Testing Developers is Hard!

Joshua Graham — Sat, 12 Oct 2019 11:19:56 +0000

One of my jobs is to hire new developers. It's something I really enjoy, as I love talking to other devs. But, unfortunately, this isn't my full time job, so I've got a finite amount of time available to evaluate and really pay attention to what our candidates are capable of.

Unfortunately, a lot of the applications we get are people who simply aren't developers. I get it. Being a developer is awesome. I can understand why they want to become one. But we get a lot of resumes for folks who really couldn't write a single line of code.

So, I had a great idea for a simple way to filter those out so I could dedicate more time to people who've worked really hard to build up their skills and get to the level we're looking for... (or so I thought 🤨). I decided to build a sort of CAPTCHA for developers!

I built out the ad site, made it look good, made sure to make the advertisement itself as specific and accurate as possible without being a pain to read... then set out to build my test.

The idea was pretty simple, I wanted to include a very basic programming test. Something that wouldn't tell me if someone was a senior developer, but would at least discount anyone who really just couldn't create even a basic function.

I found the VS Code Monaco which made it ridiculously easy to embed an editor that doesn't suck for folks to use. I built some javascript around it and described FizzBuzz.

I sent that out for some feedback and got a few things immediately. First off, FizzBuzz isn't really easy to write from scratch (unless you happen to know it). The simplest way to solve it requires using the modulo (or modulus) (%) operator, which returns the remainder after division. e.g. (5 % 3) == 2... Simple... but not common. It's rare I run into a real need for it.

So, I asked for some suggestions. I really wanted something that any reasonably experienced developer could solve in a couple minutes.

One of the suggestions made sense. It was based on a real world problem that comes up pretty often. The idea was to have a master array and a filtered array based on that. Then to remove the nth from the last object in the filtered array from the master array.... (nth means an arbitrary number, so if passed 3, then the third from the last) as I was writing out the instructions, it was clear this was more than a little convoluted. 🤪

I simplified it and made it a lot easier... just remove the nth from the last object in an array. That felt a lot easier to describe. In the editor, I supplied a function that accepts the array and the number from the last as arguments so there was a starting point.

And it was. I wrote out the instructions, built the test, shipped it for feedback again.

Everyone failed! 😲

It wasn't "difficult" and every person was fully capable of passing it, but it wasn't clear what went wrong if things didn't go perfectly the first time around. There was no feedback, it simply said it didn't work. That made it really hard to troubleshoot and also left it ambiguous as to whether or not that was the end. Did they only get one shot?

So I went back to the drawing board and iterated a bit more. I added some feedback to explain what their function did vs what I expected. I also added some extra text to make it absolutely clear it was ok to try more than once.

After all, I don't expect people to get things right the first time or to not need to play around with it a bit. Arrays can be tricky. Sometimes getting the exact position for removing something from an array can be a little fiddly!

This time the feedback was much better. The test was simple enough everyone could figure it out and the descriptions were clear enough they felt comfortable doing so.

It just really drilled home how difficult it is to make tests inclusive and open, but also effective. I wanted something that wasn't a real hassle for developers, but wasn't so simple that a non-developer could figure it out or copy/paste an answer from Google. (Mind you, I've no problem with getting an answer from Google, as long as you know what it's doing!) That proved to be a really difficult balance. I'm absolutely certain I've still not got it 100%, but what I came up with, I believe is a pretty reasonable compromise.

Time will tell! But hopefully it's a little quirky, a little fun, not too annoying and helps give me a little more time to learn about our candidates!

Join Some Tech Slacks

Joshua Graham — Sun, 06 Oct 2019 19:24:11 +0000

I posted a brand new podcast episode this week suggesting folks join more tech slacks. I’d love to get some suggestions to share.

I specifically suggested local tech slacks as a great way to get to know local developers and recruiters. But I also suggested there were others like remote worker slacks etc that can be great resources.

It's an amazing way to get to know local developers. These are folks who work for companies you might want to work for.. They can make introductions, suggest companies you should apply you and can even put you forward for positions. Getting to know them and, more importantly, letting them get to know you can be a huge boost to your career.

Equally, a lot of these Slack communities have recruiters keeping an eye on the goings on. They're looking for potential recruits, keeping an eye on (and sharing) local events and generally are really great connections to have.

Connection is a huge part of networking. I used to view networking and marketing fairly negatively, I saw the worst of it. But what I've since learned is that networking and marketing are both based around creating connections and relationships. These are mutually beneficial things that are good for everyone. Yes, some people abuse that, but you don't have to! You can create really awesome relationships with other developers and recruiters and that can be your ticket to the job you're looking for!

Another aspect that goes back to the first one. There are other developers in these communities. Not only can they point out companies to work for and make recommendations... But they're also experienced and experiencing similar things to you. They're looking for jobs. They're freelancers looking for jobs. They're developers who've created apps they're trying to market. Their experience is of value and can help you along your journey. Sharing their experience and yours is a great way to promote the community and yourself!

So, if you're a part of a tech Slack you think would be beneficial to others, I'd love to hear about it so I can share. If you're looking for specific recommendations, feel free to share those as well!

In the meantime, if you're interested in the podcast episode!

Go Join Some Tech Slacks!

Three quick tips for getting a job as a developer

Joshua Graham — Wed, 25 Sep 2019 13:15:51 +0000

Why three quick tips? Why not?! There are a lot of different tips and suggestions for getting a job as a developer, but these are three particularly great ways to stand out.

Why donuts? Because I like donuts. That's why! 🍩

1. Use everything you have to stand out.

I spent a lot of years doing the exact opposite. My resume was perfectly designed to be “normal” it had all the right content. It was formatted cleanly and minimally so as not to offend. I followed every rule of professionalism I could find.

But something magical happened when I decided I just didn’t care. (sorry.. this is as close as we're going to get to a Harry Potter reference this time around...) Someone once told me it’d better to have 90 people hate you and 10 love you than to have 100 simply not notice at all. I think that’s probably a bit extreme, but these days I’m all about showing personality and my unique traits. I’d someone doesn’t like it, maybe I didn’t want to work with them anyway! But, more importantly, it gives me a chance to be noticed!

2. Join your local tech Slacks

Get to know local developers and recruiters. Engage with them and let them get to know you! Again, you want to be noticed, don’t hide away and just watch.

(This isn’t just restricted to Slack. Local dev communities on Meetup, LinkedIn, Facebook, etc can all be just as good.)

If they’re running events volunteer to help out, even if it’s just cleanup after.

If newer developers are asking questions you can answer, answer them! If you’re embarrassed to answer in front of others, answer in private. Word will still get around that you’re helpful.

Have some opinions. If you don’t have any, spend some time researching a particular area of interest until you know enough to have one.

Which leads me to our last item....

3. Write more!

Writing articles (or making videos or podcasts) have three huge advantages.

In order to write something you need some knowledge. That likely means learning more than you know today. They say the best way to learn is to teach!

This also generates more content to gain more of that all important attention. Post your articles here on dev.to. Post them on LinkedIn. Share them in any of the dev communities you found.

Creating this sort of content also puts back into the community. The community supported you in your journey, by adding some back you’re doing your part to ensure there’s fresh content to support newer people.

That's three...

These three alone won't guarantee a job, but they can absolutely put you on the right track. Want some more tips? We talk about these subjects a lot on our podcast Getting Apps Done

Specifically it's worth checking out:

https://gettingappsdone.com/episodes/resumes-interviews-and-chainsaw-wielding-teenagers/

https://gettingappsdone.com/episodes/unicorns-in-business-suits/

Why Community Is So Important For Developers

Joshua Graham — Fri, 20 Sep 2019 15:18:14 +0000

Why Community Is So Important For Developers

Community has changed for developers

In 1995 I got my first computer and signed onto AOL (America Online) for the first time. It didn't take long before I found my way to the various chatrooms that were available on AOL and I immediately fell in love with the idea.

Around the same time, a friend introduced me to creating software. My teenaged and enthusiastic brain very quickly began drawing out UI and planning UX on paper in the evenings planning to build my own chat.

You see, I didn't just want to take something off the shelf and open a chatroom and give it a name. I wanted to BUILD my own chat.

It didn't take long before I discovered IRC and that was it. I was hooked on chats for a long time. It opened me up to an entirely new world that wasn't quite the same as the small town midwest US I grew up in.

IRC was also the default place I went to to find a developer community. We didn't have Twitter or LinkedIn. There was no Dev.to or other great hub for developers online. The term social networking didn't exist. What we did have was books, some web resources, manuals and readmes, forums and IRC.

Now, here's the rub. I found IRC to be a horrible place to learn how to develop software. The "community" was more of a clique. If you were in, you were in. But if you weren't, you were just an idiot. It was built around proving yourself and being better than others. That made it very difficult for it to be inclusive.

Some IRC channels and networks were better than others. Some forums were pretty good. Some folks were just generous and put their knowledge up freely on their websites. But it was hit or miss at best.

The state of community now

The state of the developer community was so bad, it entirely put me off for a long time. I was determined to be a developer, so I was. I learned from books and manuals and those kind people who laboured to share their knowledge on websites.

Somewhere along the journey, things began to change though. Blogging began to become more and more popular and I noticed more people were sharing their knowledge. There was a more open attitude toward people being new to things. It started to feel inclusive.

When I finally did begin to look at communities on the various social networks I was shocked to discover such huge and supportive groups of developers, entry level, senior and everything between conversing freely without fear of being laughed at, kicked or banned simply for not knowing how to do something they'd never done before!

This wasn't the developer mentality I'd given up on and left behind. This was something new and really incredible. The support I saw in groups like #100DaysOfCode on Twitter and here on Dev.to was simply awesome!

Development has changed

So, to the point of this article. Why is this such an important thing? Why is it even more important today than it was when I started developing software?

Development is hard. 😉

I could probably just end right there. I think most of us know that. Development is amazing and joyous and it's the way I've chosen to solve problems for over two decades. But it's also pretty damned difficult! It's hard to get into the developer mindset in the first place. Picking up that first language can be hell.

But it goes further than that. Development is getting harder. In some ways, things have improved so much. Better automatic memory management. Better cross platform and cross browser support. So many new tools out there to make things easier. But all those tools are also a way that things have gotten harder.

There are so many popular languages, frameworks, tools and libraries it's hard to know where to start! This is one of the most common stresses I see from new developers. "Which way is the right way?" "What should my development setup look like?" "Should I be using this tool or this one?" "What language should I learn?" There are just so many options and so many variants and methodologies that it's ridiculously difficult to know if you're going down the right path or a rabbit hole. The burden of choice! it's like being given a giant box of Bertie Bott's Every Flavour Beans with no one to tell you which ones are earwax! (I've been told every article must have a Harry Potter reference... I'm not sure if this is true or not, but I'm sticking with it. 🧙‍♂️)

Community is the way

Communities help us connect with others who are in our situation, some who are just a bit ahead of us and some who are far ahead of us. They add a huge amount of context to everything we do. They provide us with a sounding board to make sure we're on the right track.

Doing this alone is absolutely possible. But humans learn better together. We're social creatures by our nature.

So, get out there and be a little more open. Share an article even if you don't think you've got much to say. If you can't manage a whole article, just a tweet is better than nothing.

Spend a little time encouraging others, sharing your failures, celebrating successes. Every one of those things can help others and the act of being more open will help you in ways you'd not imagine!

How has community supported you on your journey as a developer?

Tips for new developers looking for their first job!

Joshua Graham — Fri, 13 Sep 2019 12:03:32 +0000

Yesterday a new developer asked me for tips and suggestions for getting their first job. One of the suggestions I gave was to get involved in local tech Slacks. Getting to know other local developers, plus recruiters can make a big difference in finding companies that are open to taking on entry level devs, plus if you get to know them well enough they may well be willing to vouch for you, and not much beats that for getting your foot in the door!

What other tips and suggestions do YOU have? What's worked for you, or what are you trying in your search right now?

You've got an interview! Yay! Yikes!? 😬

Joshua Graham — Tue, 10 Sep 2019 13:45:25 +0000

One of the most anxiety inducing parts of getting a job in software development isn't learning how to code or getting your resume into shape, it's surviving interviewing. This is probably true of most fields, but software companies seem to go out of their way to find new and creative ways to pile on the stress!

From phone interviews to Skype video conferencing straight on through to in person interviews, they're all absolutely nerve wracking and can make even the most confident people a little jittery.

It's so easy, when you're nervous, to say the wrong thing, or to hesitate longer than you'd intended, to second guess everything you've said or how you sat or what you were wearing or whether your webcam is straight or not.. did they hear you humming Hedwig's Theme in the waiting room? 🦉 Did you really leave your laundry pile on that table back there... will they notice if you quickly move it? 👖👚👗👕🧺 🤯

I've been through quite a few interviews over the years and sat on both sides of the table. To this day, I get nervous, regardless of which side I'm sitting on. I'm absolutely not an expert on how to overcome all your fears and anxieties or how to nail every single interview, because every single interview will be completely different. Hopefully, though, I can share some tips and advice that will make it a little less terrifying and a little more successful.

Practice, practice, practice!

Above all else, practice makes something closer to perfect! Anything you can do to make the interviewing process feel a little more normal is going to make things go a lot smoother.

Do some mock interviews with a friend, current co-worker, find someone online who's willing to pick up the phone, your neighbour, the cashier at the shop down the road.... ANYONE willing to read some questions out to you, this is a huge step forward.

Practicing this, even with someone you know, will help you solidify what you want to say and how to say it. Note: I don't generally advise memorising and repeating anything verbatim, but having a good idea what you want to say and how you want to respond will make it easier to respond to similar questions in the interview.

If you can find a mentor, someone who's a year ahead of you, maybe even a couple mentors, someone a few years ahead, 10 years ahead... Get advice from them. Practice with them. They'll be able to learn more about you and help you identify things you might struggle with in an interview. (If you don't know anyone else, drop me a line! We can chat!)

Once you've done those things, start taking interviews, even if you're not all that interested in them. You might be surprised! Sometimes interviews taken on a whim turn out to be game changers. Nothing beats a real interview for practice. And if you're going to bomb on a real interview, it might as well be for a job you're not sure you want! 😁

You don't know what you don't know and that's ok!

Inevitably, unless you're applying for a role you're drastically overqualified for, you're probably going to run into a question you don't know the answer to.

I've seen a lot of advice on this one, suggestions like talking around the subject.... I tend to get right to the point. Just flat out tell them. "I don't know." That can be a perfectly valid answer on its own. If you feel they're looking for more, a good way to follow that up is "But, this is how I'd go about figuring it out..."

It's ok not to know everything. Tech is huge. It's great to know things, but it's a lot more important to know how to figure out the things you don't know.

There are also a lot of cases where you DO know the answer, but don't realise it. If you're unsure what they're asking for, you should absolutely ask them for clarification. "Could you please explain what you mean by binary search tree?" Sometimes just getting the definition is enough you can go work out a solution for it.

This is a really common issue in tech, as not all data structures, techniques, patterns, etc have the same names in every language, framework or methodology. We also have a habit of using acronyms for absolutely everything! Sometimes names can be different by industry or region as well. Asking for clarification is absolutely ok.

Teach others how to pass whiteboard tests

They say the best way to learn something is to teach something. There's a huge amount of truth to this. In order to be able to teach another person anything, you need to know more than you'd need to know just to do the thing in the first place.

There will be a lot of things you might know well enough to do them on a daily basis. You might have enough knowledge that you can figure something out with a quick Google and that's good enough when you're working. But in an interview situation you don't always have access to Google! (You should... because it's completely unrealistic to NOT have access to a computer and the internet while programming... but interviews are what they are!) You still need to be able to answer those questions and the best thing you can do is over-prepare.

By learning how to teach others to pass whiteboard tests, you put yourself in a better position to pass them. It's also a great way to pay back the community of developers who have supported you in your journey!

Remember, you're interviewing them too!

This is one that a lot of people miss and it's a shame. If a company hires someone who's not a good fit, they might miss out on some time/money, but most won't really struggle. If you take the wrong job, it can be extremely harmful to your financial and/or mental health.

You should absolutely be interviewing the company more than they're interviewing you. You should be looking for a situation that feels right to you. Where you'll be respected for who you are and what your current capabilities are, but also encouraged and enabled to grow and learn more.

What's important to you will depend on you. For some people it might be about flexible working hours, will you have a mentor to help you grow, do they offer remote working, what sort of clients do they work for (sometimes this can be a really big deal!), are there opportunities for supporting charity events, social activities, work-life balance, etc. Ask the interviewers directly, ask to talk to some people who would be your co-workers so you can ask them. It's well worth taking the time to do this, as these things make a huge difference in finding a great role over one that just pays the bills.

The person interviewing you might have no idea how to interview you

When it comes down to it, the people who will be interviewing you have other jobs. They may well have never interviewed someone before!

The first time I interviewed someone for a technical job I was 20, I had no clue what I was doing! 😬

This is something a person has been asked to do between their normal duties. There's a good chance they're hiring because of a high workload, so this person might well be stressed out and strapped for time.

That's a lot of factors that could lead to them doing a lot of things that really aren't going to help them gauge whether you're a good candidates and a lot more things that could make this a really uncomfortable experience for everyone involved.

This is a good opportunity to try to be accommodating and understanding of the situation they're in. Going in with some empathy and a good attitude can go a long way toward making everything go smoother.

Have a drink!

No, not an alcoholic drink! (Maybe after! 🍾) While I'm sure that could calm your nerves, that's probably not a good idea!

You're going to be talking a lot, which will dehydrate you and dry out your mouth quicker. It's a simple thing, but when they offer some water, take it! There's nothing worse than trying to answer questions when you're parched.

Also, did you know that when your mouth is dry, you make more clicking and popping noises while speaking? (Fun lesson learned from podcasting! 🎙) Having a glass of water at the ready can help with these. It's not the sort of thing people actively notice most of the time, but I try to avoid clicking and popping at the people who are interviewing me. It just doesn't seem like something I should do. 😁

Be you!

I say this all the time when talking about resumes/CVs. But this is entirely true in an interview as well. A big part of the interviewing process is deciding whether or not you'll be a good fit in the team. There are a lot of different ways this is done, some good, some bad. Most somewhere between. But you should always be you.

By pretending to be something else you're sabotaging this for everyone. If you're really not a good fit, or if they really don't like you for who you are, this isn't going to be a good experience for you.

Now, I know, when you've got bills to pay and just need a job, sometimes "good experience" takes a back seat. I totally get that. If that's the case, then your best bet is always going to be to get yourself into a position of financial safety first, THEN go find something that's a good match.

In general, though, if you can be yourself and find a team that appreciates that and gets value from your unique knowledge and personality, that's the best situation to be in.

It's tough, but it's worth it!

There's a lot going on with interviewing. There are a lot of different personalities involved. There are also a lot of pressures on both sides to get things right. All this leads to interviewing being one of the highest stress points of becoming a software developer.

In an ideal world, you'll run into an organisation and an interviewer (or interviewers) who work hard to make this process smoother and less stressful, but that might not be the case. They might not even be capable of doing that.

When it comes down to it, though, if you don't get this job, you'll learn a lot from the experience and take that with you to the next interview. There are so many jobs out there for software developers and so many ways for us to differentiate our skills.

Keep learning, keep trying! It won't take long before you're back here announcing your new role! In the meantime, if you've gotten this far, you're a real software developer already. Welcome aboard! ⛵️

If you'd like some more tips and information about building your resume and interviewing, we talk about these subjects a lot on our podcast Getting Apps Done

Specifically it's worth checking out:

https://gettingappsdone.com/episodes/resumes-interviews-and-chainsaw-wielding-teenagers/

Your First Day As a Developer

Joshua Graham — Fri, 06 Sep 2019 16:01:40 +0000

So, you've learned all the syntax and patterns, written a hundred and fifty-four apps demonstrating different abilities. You've graduated university or bootcamp and stocked your resume chock full of awesome. Your portfolio is looking sharp and really shows off all your skills and abilities. You've survived 38 phone calls, interviews and rejections with little to no feedback.

You've found that one employer who looks right. You were smooth and suave. You nailed that Fizzbuzz backward in ANSI C on the whiteboard while blindfolded and they've offered you a job!

At the end of it all, a large gruff man with a large grizzled beard has informed you: "yer a developer Harry!" (Ok... maybe not that one...)

Now what?

What should you expect on your first day as a developer? What shouldn't you expect? What's going to be expected of you? These are the sorts of questions that could keep a new developer up at night worried, battling with impostor syndrome, burying themselves into books about best practices and dealing with headless branches in Git. (Sounds like a horror story... 🎃)

I recently enjoyed a conversation with my podcast co-host, Kel Piffner about exactly this topic. We came up with quite a few things that really do cover a lot of what to expect as well as some things we've seen a lot of new developers come in expecting that were way off base.. Without further ado and wizard references... 🧙‍♂️🧙‍♀️

You aren't going to know what's going on

Even experienced developers will walk into a new role and be completely lost. Unless this is a completely green field project, there will be a history of code, architecture, infrastructure, constraints and processes in place. These will have grown organically and won't be exactly the same as any other environment you've ever worked in.

This is completely normal! It's a lot to digest and it takes some time to memorise them and know your way around all the different aspects that make up software development.

How are projects managed? Is there infrastructure in house or is it all in the cloud, what the hell is Server08? Oh, that's the UAT server. Wait... What's a UAT server? FYI: User Acceptance Testing (UAT) is like a proposed release in a special environment for end-users to give it a go and make sure it meets all their acceptance criteria... the things they wanted in the first place. There may well be special change control processes in place, the code will be arranged in a particular manner. The company might use micro services, serverless setups, massive crazy continuous integration processes, etc.

These are all things you'll need to learn and understand. Even if you know what everything is, you still need to figure out where things are and how they fit into the grand scheme. It's daunting, but... again... perfectly normal.

The tech stack

I've seen a lot of folks show up and be surprised and upset by the fact that they weren't able to use their preferred tech stack or tools. You don't get to pick the stack you're going to work with.

There will likely be a rich history of technical decisions and organic growth which has caused a particular tech stack to be in place. Or there may well have been a concerted effort to make the decision to use that stack. In either case, what you see is what you get and you're going to have to work with it for the foreseeable.

That doesn't mean everything is set in stone. There may well also be exceptions to this. In general, though, you'll be well served to accept this and start learning as much as you can about the stack you've got to work with.

Your new team!

Hopefully you'll be working with other teams. The company you work for may assign a mentor or buddy to you. They might even assign multiple! Or they might not assign anyone at all....

You are absolutely within you rights to ASK for one if they don't tell you who to ask questions and get advice from, but when it comes down to it every organisation has their own policies for how teams are structured and how on boarding new developers works.

If the company you're working for doesn't offer any of these things, talk to the other developers on your team and get to know them. That can be an excellent way to build a rapport with them as well as finding unofficial mentors!

At the very least, in most organisations you'll be paired up with someone early on to walk through the project(s) and give you a bit of a tour. It's important to pay attention to this, but most folks won't expect you to memorise absolutely everything you learn on the first day (or days)!

Getting help

One of the most important things you'll learn in the first days of your new job is how and where to get help when you need it.

Communicating well with the team is going to make everything go smoother for everyone! That means asking questions when appropriate. If you're stuck on something, you've given it a good go for 30-60 minutes and you're not getting anywhere? Ask someone. Think you know what someone asked for, but you're not sure? Ask them to clarify. It's much better to ask a few more questions now than to go spend two days building the wrong thing!

Back to tech stacks and tooling, if you don't understand why something is in use, it's perfectly ok to ask respectfully about it. "Previously I've used X, it worked really well. I noticed we use Y here, could you explain it a little to me?" goes over a lot better than "I always use X, it's so much better than Y. Y sucks."

I don't know how many times, early in my career, I declared that X was vastly superior to Y, only to have someone more senior explain Y to me and realise I was completely wrong! Don't be me! 😬

Some things expected of you

Above all else, in a new position, you're expected to be willing to learn. As a bunch, I think developers tend to be pretty open to this, so I don't think I need to discuss it too much, but it is probably the single most important thing.

Some things that might be less obvious:

Estimation: You should be able to estimate how long tasks will take you. The better you are at estimating, the easier it makes things on everyone else. They'll be able to plan around you easier and will begin to trust you much faster than if you don't have this skill.

Setting expectations: This is a huge part of communication. Being able to set expectations appropriately makes all the difference in anything. If someone asks for something, make it clear what's involved, how long it will take and what the risks are.

Infrastructure: Having some knowledge of infrastructure is extremely beneficial in all IT. It's not traditionally the role of developers to understand a company's infrastructure, but knowing this helps you develop software better and gives you a greater understanding of what's going on with the software in general. 🖥

Process: Following the existing processes and understanding them is hugely important. This is part of how a team works together. If you're not following the process that can make things much harder on everyone else. So learn them and use them!

You're an important part of the team

Don't go into this thinking there will be senior developers who are shining examples of wonder and splendour. (I am, of course.... 😁) There will be other developers with other experience. They might be more experienced at some things and less at others. But their value doesn't negate yours!

You provide value to the team, and by learning you add more value to the team. It's in everyone's best interest to support that. So always keep in mind that you asking questions and learning is a contribution, not a bother or a nuisance!

There's a good chance you won't be writing code!

In most organisations you're not going to be writing much code at first. It's possible you'll get to work on some low priority items, but there's a very good chance you'll actually be tasked with a non-development job at first. Don't take it personally.

A lot of organisations will start new developers off vetting tickets. I'm a huge fan of this. This is one of the best ways to become a better developer. It's a very different point of view that is extremely important.

You immediately get to talk to the end-users, understand their frustrations as well as their mindset. You start to build mental images of their user personas which will help you make decisions that will improve the product in the long term.

It's also a really great way to get to know the product. By the time you're done verifying issues do exist or figuring out why you'll know the product inside and out. You'll start to understand it's strengths and weaknesses as well as its overall structure.

Take advantage of this opportunity, don't be offended by it! This is a good way to ease you into a new role while allowing you to provide value early on. Providing useful debugging information and possible solutions as well as keeping the queues clear will make you the senior developer's best friend very quickly!

It won't take long at all before they're happily pairing with you or allowing you to write your own bug fixes and feature additions.

It’s going to be different than you expected

I think the big thing to keep in mind is just that it’s going to be different than you have in your head. You’re going to be different as well. You’ll discover some things you thought were strengths really aren’t and you’ll discover new strengths you never knew you had.

It will be weird and wonderful and terrible all together. But this is the start of a journey that has so many possible routes and options!

I’d like to leave you with one parting note before I finish rambling. Many of the developers I see taking entry level positions now are better developers than I was while getting paid to do it professionally! 🤯 Give yourself more credit than you believe you’re due, because you’re probably going to be your harshest critic!

If you’re interested in listening to Kel and I chat about this on our developer podcast check out the latest episode at: https://gettingappsdone.com/episodes/your-first-day/

Go Break Some Resumé Rules! (or not!)

Joshua Graham — Thu, 29 Aug 2019 19:16:02 +0000

A lot of the rules you'll have learned about resumé building aren't all they're cracked up to be!

I remember in school we had a course on writing resumés (known as CVs on this side of the pond!). We were given examples of how to format it, a set of rules to follow and told to go make some.

I'm glad they set aside some time to talk about this, but most of what we were told turned out to be crap. 💩

I'd like to start off by saying, all rules about making resumés are not rules at all. They could be suggestions or guidelines, but there are absolutely no rules.

Your resumé doesn't have to be plain and boring so as not to offend other people. If you like pink, use some pink. If you like pink fluffy unicorns 🦄, then you go on and chuck in some unicorns.

I love helping folks with their resumés and this one comes up a lot when I'm reviewing them. Every single resumé I look at is pretty much identical. If I've got a stack of 20 of them to review to give feedback, or a stack of 100 to look for candidates to interview... it's just a stack of nigh on identical boring resumés with very little to separate them.

So the first piece of feedback feels a bit like marketing 101. It's better to have 90 people absolutely hate your resumé and chuck it in the bin and 10 people absolutely love it, than to have 100 people not notice it at all.

.ltag__user__id__214934 .follow-action-button { background-color: #161616 !important; color: #66e2d5 !important; border-color: #161616 !important; }

Kel

Developer: software | processes | people. Likes cookies 🍪. they/them

KellenPiffner https://kellen.piffner.com

In fact, this can be an awesome thing. Kel, my co-host on the podcast, loves to refer to this as filtering. You can filter as much or as little as you feel comfortable doing, but filtering allows you (and prospective employers) to try to find good matches. When there are no filters, no controversial items in there, nothing that really stands out... then neither side is getting any benefit.

When it comes down to it, your resumé is your elevator pitch. It should lead the person reading it to want to know more about you. Once you've got them hooked, then make it easy for them to find out more. Draw them in and keep them interested!

How to make your resumé stand out

Ok. So it's good to stand out from the pile, but how the hell do you do that?

You be you. What's unique to you? Use your unique experiences to promote you! When someone is looking for candidates, they will have some interest in tech stacks and history, but they're also looking for another human being that's going to contribute to the team.

My sister has one of the best relatively unique pieces of background information. I haven't quite convinced her to use it yet, but it's awesome! She spent some time working with AmeriCorps. Beyond purely being an awesome way to contribute to society and, in her case, doing good work to maintain natural areas, she gained some amazing skills that apply to so many other roles.

She spent part of her time leading a team of young people, most between 18 and 25 doing trail maintenance. We're talking about a bunch of teenagers running around with chainsaws... and no one got hurt. Seriously... Who wouldn't take one look at that and think, "now that's some amazing team leadership!"? Even if I'm looking for software developers those skills are invaluable.

You're looking to stand out, and the things that are unique to you, are what really make that happen. That includes your experiences and your personality, which is another area that's often neglected, or done because someone was following a rule.

Some folks say you shouldn't put anything personal on your CV. Some say you absolutely must. A bit contradictory there... My view is, once again, you be you. Demonstrate your personality by deciding for your own damn self! If you want to slather your CV with unicorns and rainbows, go for it! If you want to show off your design chops and create a modern and amazing experience? Rock on! If you prefer logic and order, show off with a nicely organised minimal setup. No matter what choice, some people will love it, some will hate it. But that will always beat everyone ignoring it.

Information architecture.

Now, I said if you're logical and like order you should make it nicely organised, but this goes for everyone. Information architecture is key. You're building a user experience.

One thing I see a ton of is just following the tried and true format. Name and contact details at the top, followed by a summary, followed by work history, followed by education.

That can be ok, but put a little bit of thought into it. If your education or personal projects are more relevant to the job, then put them above your work history. Put some order to the information to help people find out why you're a good fit.

In addition to organising the information, you need to really think about what you WANT to say.

Don't just flood your resumé with as much information as you can. It can be very tempting to just type out absolutely everything you can think of so you don't miss any opportunities. But what will end up happening is you'll create pure information overload. No one will be able to find the important things! This is definitely a quality over quantity situation!

Do think about some of the types of content you need. One that often gets overlooked is what I like to call "keyword fodder". Most of us will be submitting resumés to job sites where agencies and "head hunters" will be doing keyword searches. It's good to have simple sections that tick the boxes for those.

Along with that, make sure you add context. If you claim to be an expert in Java, make sure you share why. Which roles did you use Java for? How did you use it? How long have you been using Java? I like to stick in a section of my favourite languages and put years next to them.

Note: I'm not a big fan of using stars or any other form. If you tell me you've been developing Python for 3 years, that's something specific. If you tell me you're a 4 star Python developer I'm left wondering... what do you class as a 4 star Python developer?

Bonus: Don't forget the cover letter!

I've actually had people tell me they thought cover letters weren't a thing anymore. This couldn't be further from the truth! Cover letters are the perfect opportunity to be specific. Who are you and why are you, specifically, awesome for this job, specifically?!

Once again, there are no rules. This is a letter from you to the person who's going to read your resumé! Share with them what you think is important!

Bonus Bonus: Github and portfolio

I can't tell you how many times I read a resumé and somewhere in there find a link to their GitHub account. This sounds great in theory. What usually happens is this: I arrive at their GitHub. They have 158 repositories for every single little piece of project work they did in bootcamp or university and I have no clue what I'm supposed to be looking at!

You can star some repos, create really great readme's to explain why this repository is important. What am I looking for? Did you come up with a novel solution to a specific situation? Did you learn something really important while working on it? Did you create an awesome looking interface? Toss in some screenshots! Maybe even a GIF showing off some functionality! Make it easier for me to know why I'm looking at this.

I also strongly believe in building a portfolio site, particularly for frontend devs, but this can be great for everyone. Concentrate the information you want to share! Build some case studies to show off your process. How do you tackle a project? Guide someone through your experience and skills. Show off with a video walk through or twelve of things you've worked on.

So go be you, stand out, do your thing, break some rules

When it comes down to it, a lot of this is about letting you shine through in your resumé and remembering that the rules really aren't rules, even all the things I said in this! If you feel most comfortable following the rules, that's absolutely ok too! But if you do want to break a few, go for it! 😁

Want to know more? We've got a couple podcast episodes that have even more ideas about resumés and interviewing!

Also, if you want some feedback on your resumé, feel free to drop me a note! I'd be happy to check it out and get you some honest feedback.

We're All a Bunch of Impostors!

Joshua Graham — Tue, 20 Aug 2019 15:52:51 +0000

Impostor Syndrome isn't just for new devs

When I talk to newer developers, there's clearly a struggle with impostor syndrome and the frustration of simply not having all the answers. I've had people ask me questions like, "am I smart enough for this?" and so many comments like, "I'm an aspiring developer." from people who are building more complex software than anything I built professionally for a number of years.

I wish I could say that goes away just by gaining in experience, but I can't tell you that without being a lying liar! 🤣 I've been developing software for nearly 25 years and have worked for a lot of companies on a lot of projects and still suffer just as much as ever.

My faith in my ability to build apps has increased drastically, but I still feel like I did early in my career: I'm always looking at other people who know things I don't.

We focus too much on what we don't know

Tech is huge. There's so much out there to see, learn and understand. It's very easy to find things we don't know. It's the same for everyone in this field. When we see someone else who DOES know those things, it's easy to feel like they're ahead of us; they're the guru and we're just faking it.

Sometimes it's hard to put this in perspective and focus on what I DO know instead of all the things I don't. (Let me tell you... that's a big list... 😛) It's hard to stop looking at what everyone else knows, has achieved or is doing and, instead, focus on me. What do I know? What have I achieved? What am I doing that's awesome?

No one is doing us any favours!

When I was in school, I remember teachers and advisors telling me all these things I needed to know. Particularly as I had an interest in computers, they were insistent I had to go to university. I had to study calculus, because I'd use that all the time!

It got to the point I really started to debate whether I wanted to be a programmer at all. I'd been working on personal projects for a couple years. I'd even made some money building websites for people. But everyone kept saying I needed to be awesome at math and know all kinds of things I really had no desire to learn.

It was daunting. It was discouraging. In fact, it was enough I put programming aside for a while and did IT support instead. (Which is something I'm very grateful for, but that's another story entirely!)

As it turns out, I didn't need to know most of those things. I'm not working on advanced algorithms. I don't use trigonometry or calculus on a daily basis (or ever, really..) I use some geometry and some algebra... and that's about it. There are certainly some specialised branches of software development where more advanced math would be useful, but you don't HAVE to learn any of this stuff if it isn't your thing! You can still be an awesome developer with the skills and knowledge sets that ARE your thing.

You don't have to get it all right today

I recently posted about failure, I've been talking a lot about this concept lately, as it's not something many people want to talk too much about. We're told in school that we have to do well. We have to get good grades and if we don't, it's too late. We're built up to believe there's some cut off point where we've just failed.

But failing and learning from our mistakes is part of growing. Just because you don't know something today doesn't mean you won't know it tomorrow or in a year. You don't have to know everything. What you do need is to know how to learn it when you need to.

There's a huge amount of anxiety and stress around this in bootcamps and universities. Worry about not knowing every type of sort or recursion pattern. Fear about not knowing every command Git has or being able to recite off the top of the head exactly how to do a binary tree search.

I get it! Whiteboard tests are real. They're also really crappy. (Again, a message for another time, but I really do hate whiteboard tests!) But most of these things you'll naturally learn on the job. You'll get used to them. In fact, I'd fail most whiteboard tests purely because I learned these by necessity and don't know the names of half of them! But you can and will learn these things well enough to pass the test and get a good job if you stick with it.

Learn to embrace you

When I talk to new developers and look at their Github repositories, a lot of them look the same. I'm really not interested in whether they can recite anything off the top of their head, or immediately know the answer to any arbitrary question or if they've got a repository for every single dev skill in the book they were learning from... I'm looking for people who have their own unique skills and interests.

Instead of worrying about everything we "should" know, I think it's better to embrace who we are. Enjoy what you enjoy, learn what you want to learn and spend more time discovering what makes you happy. Have more fun doing personal projects that are zany and eccentric or if you love beautiful code, do that and highlight it. Build amazing solutions to mundane things or simple solutions to extremely complex things. Figure out what your thing is and focus on that.

One side of impostor syndrome is that we're constantly comparing ourselves to other people... who aren't us. In fact, most of the time we probably wouldn't want to be the person we're comparing ourselves to.

I, personally, find myself comparing me to people who are really great at refactoring or design or new developers who are still so excited about everything javascript. I envy them a bit before I remind myself I wouldn't want to be any one of them. I'd go crazy. That's not me.

If you're new to development

If you're reading this and you're a beginner to development, I'd like to offer a few tips that might help you put some things in perspective.

New developers are awesome. You're so enthusiastic. You haven't been siloed into a particular way of thinking and you bring a huge amount to the table simply by being new!

Ignore what everyone has told you about being a developer. (except me... clearly 😉) Your journey is your own. There are so many ways you can fit in and be an amazing developer that no one else's experiences or knowledge will exactly mirror yours.

Don't stress about job specs. I know, they have a huge shopping list of "requirements" on there, but most of those are simply not requirements. Apply for the job anyway if you think it's a good fit. Write a great covering letter explaining why you think you'd be perfect for the job with or without those required skills! Cover letters are so underrated!

Learn as much as you can about the things that interest you. That's how you'll specialise. That's how you'll find what you're great at. Don't worry about what anyone else is doing. Experiment, if you decide you don't like something you learned, try something new! Embrace those differences! They'll make you stand out.

Finally... give yourself the credit you deserve. You're a software developer. If you've only written the TODO app example or a small shell script, you qualify!

One last note: Kel and I talked recently on the podcast about building your CV/resumé and standing out. We talked about some of the topics in this article from a slightly different perspective. Be sure to check that out too! We may or may not also talk about unicorns in this episode... 🦄 So if that's your thing... we've got you covered!

Failing Doesn't Make You a Failure

Joshua Graham — Mon, 19 Aug 2019 13:29:32 +0000

Failure Is Normal

I screw things up all the time

I got my first computer in 1995 I was introduced to Visual Basic by a friend and pretty much immediately decided programming was what I wanted to do. I've been doing it ever since. A little bit on and off, but mostly, yeah, pretty much since then.

So it's been almost 25 years now. I currently work as a consultant. I run a lot of development teams for a lot of different companies. We have a variety of clients, everything from well established finance and engineering companies to small startups.

I think there a lot of misconceptions about what a developer should be and what we are and how we judge each other and ourselves... probably more ourselves than anybody else... that I think are really wrong and they're hurtful to us and they don't make us better developers at all.

Throughout my career I have built a lot of software. I have created my fair share (maybe a few more... 😬) of null references, caused quite a few infinite loops, caused machines to blue screen, to crash. I've taken out entire server rooms in the past....

I don't tell you these things because I want you to think I'm a bad developer. I want you to know this about me because that's all normal. Ok... to be fair, not everyone will take out an entire server room... But it's normal to make mistakes, to get things wrong, even to just downright screw up.

While I've made mistakes, I've also learned a lot from them and built a lot of software that has been used by thousands of people and stood the test of time.

I feel that's something that we miss a lot. We get this idea that failing is bad. It's very easy to relate failing to being a failure. And we forget that failure is normal; failure is a part of growth.

But it's normal to fail

So I think to start with, it's really important to just know that it is okay to fail. You can still be a rock star developer, you can be a huge asset to a company, create a huge amount of value and be open to the fact that you're going to fail.

I think we all need to kind of keep that in mind because we don't know all the answers. In fact, when I'm hiring a new developer, the first thing I try to find is not that they know all the answers. I typically try NOT to ask them many questions that they have to give me a direct answer to.

I ask them to work with me and to learn with me about something that they don't necessarily know. Because I think it's much more important that you can find the answers; that you're willing to learn and look and seek because, let's face it, even if you do know every single answer today you won't in a year. That's the way tech is.

Failure is a part of growth

I think we can do that by allowing for failure and failing quickly. We should push the boundaries a little bit and increment ourselves just a little bit at a time and push ourselves forward through that process.

There's this concept of progressive overload that's very popular with weightlifting, but I think it works in everything in life, particularly in development.

I remember when I was younger, I played a lot of video games. (My parents swore up and down I should work more on getting jobs and less on playing video games! Sorry mom and dad! 😁) In video games, the best way to level up was to go fight the bad guys who were beyond your current skill level, because you got a lot more experience for them. That was the quickest way to level up.

It's the same with development. If you push a little bit beyond your comfort zone, get outside of that and open yourself to... maybe bombing on this one, but learning from it. Then, when you do screw up, admitting: "Okay, I really screwed this up. What can I do better next time?" Then picking up and moving on from that. Get feedback from others, learn and improve yourself. That's the way to push yourself forward and get closer to being a really great developer.

Safety is a key

The problem is, it's very easy to say failure is ok and normal, but it's very hard to admit to failure because, in general, most of us have a reason to want to avoid that.

I'm scared because, let's face it, I've got kids, I've got to feed them, I've got a mortgage to pay. So when someone who's in some way controlling the money I have to pay for those things is asking me questions, I don't want to admit, "I don't know that" or "I've bombed that" or "I've screwed that up" because I can't do that safely.

Unfortunately, most places are not, as a default, safe places to admit failure. There's a chain of fear. When you tell your boss you did something wrong, they have to tell their boss something went wrong on their watch. When you're in an interview and you don't know the answer to something, even if the person believes you are able to do the job, they're afraid if they bring you on and things go wrong, they'll be held responsible.

In most situations, one of the best things we can do for ourselves is put ourselves in a position of safety. I'm going to admit, right now, this is something easy to say, but harder to do.

Money

One of the single greatest things you can do to put yourself in a position of safety is to put yourself in a good position of financial safety. Pay off any debts you can. Build up a little bit of money, even if it's just to cover your next month.

It's incredible the amount of freedom you get to say, "actually, you know what? If I screw this up, it's probably going to be okay." It's just amazing. It doesn't take a lot to get yourself in a position where you feel a little bit more okay about take a little bit of a risk here and there. As we said, you've got to push yourself a little bit outside of those comfort zones and take a few risks here and there. And the more comfortable you are with that, the more you're able to do that.

Have a backup (and/or back out) plan

Another really great lesson I learned early in my career is: have a backup plan. It's a numbers game. Eventually you're going to fail. It doesn't matter how careful you are it doesn't matter how many scenarios you plan for. Eventually you're going to miss something. Knowing what you plan to do when that happens can make all the difference in the world.

Early on, I had a manager who was absolutely awesome. He allowed me to go push my boundaries. And when I did screw things up he would show up right there and say, "okay, so this happened. What are you going to go do to fix it?" He would then proceed to protect me from everyone else while I did what I needed to do to sort the problem out and learn from it.

And at the time I didn't recognize how important that was, but that was one of the steps in my career that allowed me to understand, okay, so first off, failure is normal and second, I'm going to learn something from this. I'm going to figure out how to fix this. And it didn't take long before I was coming back to him the moment something went wrong, saying, "hey, I screwed up. This is what I'm going to go do. Is that okay?" And he'd say, "yeah, yeah, go for it. Get it done.".

I think having that lesson, learning how to create a backup plan to then not hide from it... not to brush it under the carpet or blame somebody else, but to actually just say, "yeah, I did this..." helped me change how I approach problems.

Transparency changes the picture

I think it's a very good way to begin to be a bit more transparent, to begin to be a little bit more open because most of us are hiding a lot of stuff. Just the act of not hiding it, simply by saying, "you know what? I screwed this up." It makes it okay for somebody else to say, you know, I screwed something up too. The next time, something comes up and they screw something up. They're much more likely to say, "yes, actually I did this. How do we get out of this? What do we do now? What's the next step?"

This is huge for leadership and for teams. There's no magic to it. There's no action plan. Honesty and transparency and respect go hand in hand and tend to spread on their own.

For developers, if your leadership isn't doing this, support each other. Be honest and share with each other. This is what I think of when I think about rockstar developers. This is what I want to be and strive for every day: Not knowing all the answers, but learning new ones all the time, being more open, being more transparent and pushing myself and others forward.

If you want to know a little more about safety and transparency, Kel and I have a couple podcast episodes about these topics:

Put On Your Hardhats!

Failure Is Good!

Also, this is based on a talk I gave at LeicesterJS. You can listen to that talk on the podcast as well!