Forem: Inktrap

Introducing the Wonderful Weekly Workshop

Jon Barker — Tue, 09 Jun 2020 14:13:39 +0000

A long time ago in an office far, far away, a conversation during our weekly design chat turned to how we could work on developing our UI skills. Then, an idea struck…

At Inktrap our design philosophy has always been to make sure everything we create has a purpose, that it is useful and looks great too. Although this is something that we all believe, it’s easy for visual creativity or the artistic element of design to take a back seat where we become so focused on function. As designers, we get excited by bold colours and interesting shapes and sometimes within product design we don’t get to flex our artistic muscles as much as we would sometimes like to. We believe design should always be about the user but there are times we want to design for ourselves just for the sake of trying things out and experimenting to see what might happen.

Freedom to fail is really important to us. Even though we have clients who are open to being challenged and pushed in new ways there will always be an element of caution in the work. Most of our clients are either starting a new business venture or only a few years in, so it makes sense to not take huge risks with their UI styles.

When we remove the client or real users from our work we’re provided with space where we can experiment for the sake of it. It gives us the opportunity to ask ourselves ‘what would we create if we had no one to impress’ and this is a great challenge as a designer because we then start tipping into becoming an artist.

Getting us out of our comfort zones

Though there is plenty of scope for us to improve our UI and general product work, it’s easy to design in a vacuum if we only look towards styles and visual aesthetics that are already in our industry and area of design. It’s even easier to rely on our tried and tested styles and approaches. Many may think ‘if it ain't broke then don’t fix it…’ which can be true, but if as a design team we want to progress and move forward that means we need to actively challenge ourselves.

Challenge our quick design skills, and decision making

Usually, our projects are a minimum of 2 weeks long. Which is a really nice chunk of time, it allows us to get our teeth into the business and user problems but quickly enough so that the client gets something tangible at the end. Having a longer period of time enables us to have a holistic approach to the project, but it is possible to overthink things — e.g should I use this shade of blue, or should I use this purple instead. Having a short task each week meant we would have to be decisive and focus on progress over perfection.

Get us more comfortable talking about our own work

It’s known that although designers can generate amazing visual work sometimes we’re just not that good at communicating what we’ve done and why. There can be a variety of reasons for this and presenting your work well is something all designers should practice more. Sharing our work together means that we can learn from each other about design decisions in addition to learning how better to present our ideas.

Get us more comfortable reviewing other people’s work

At Inktrap we want to try our best to create a space where everyone feels that they can be honest and open. That means we need to create connections of trust between ourselves. Feedback can always be difficult, that’s why we believed providing feedback on low stakes work is a great place to start. Making something we aren’t overly precious about means it’s easier to receive critical feedback.

Generate a rough idea that might spark new ideas in our client work

Sometimes it can be hard to think of ideas on the spot, that’s why we usually have our best ideas when we’re away from the computer and away from the task at hand. These ideas can easily be forgotten, and IDEO's Tom Kelley’s likes to have a dry wipe maker in his shower just in case. Ideas saved for later are a great way to spark inspiration when it feels like the idea barrel has run dry.

Once we defined the benefits of conducting the workshops we set about creating their structure. Though we loved the idea of having open briefs we realised we needed to set some restrictions to keep us focused, so we made a set of rules. These rules weren’t concrete but were there to give us guidance as we got comfortable with undergoing a challenge like this. The rules were…

We have 30 mins to design. Rough and ready, nothing needs to be neat or polished.
All design work ends up in Figma. You could do something on a sheet of paper or in Illustrator, Photoshop etc. if you wish, but bring it back into Figma for ease of presenting.
We will each have 1 min to present our designs, then 5 mins for us all to discuss the work and provide feedback.
Everyone must keep it fun!

And we followed those rules! As with everything, our on-paper-plan was different from the reality of these workshops. Some weeks were more frustrating than fun and once we got into the flow of things, we didn’t need a rigid one minute for presenting and five minutes of discussion.

Putting an idea into practice

The design team gathered virtually on a Wednesday morning and we had a go at our first Wonderful Weekly Workshop. Using a random chooser I selected a design style and a thing we were going to redesign in said style. We began on a tough one. Facebook and renaissance art!

It was excellent!

It was a real test of our design skills and a challenge to get us thinking in a completely different way. It was interesting to see how some designers stuck with a modern UI but added flavours of the renaissance style — colours, curves, and fonts — and how other designers completely re-thought the application of Facebook to a renaissance setting, using portraits instead of statuses.

After creating our designs, we reviewed the work we had done. The design team found the art style of renaissance particularly hard to apply in a modern web design setting but still had fun giving it a go. We really enjoyed it as a break from the week that was both fun and beneficial. There were, naturally, some initial reservations on how actually useful this was going to be for our design skills but everyone was open to continuing it.

We discussed what could be improved in future workshops. The main thing we learned was that the purpose of these workshops needed to be clear. The goal wasn’t to create a beautiful, perfect piece of work, but to test ourselves and push the limits of our comfort zone. We also found it hard to talk about the work we did and vocalise our reasonings for certain design decisions, so we decided the facilitator should ask some questions to jump-start the discussions about our own work.

A weekly affair

The first session was such a success that we decided we would make it a weekly workshop, and so the Wonderful Weekly Workshop began! It’s now been 12 weeks and we plan to continue it onwards and upwards for as long as we feel it’s fun and beneficial.

The design team enjoyed it so much and spoke about the workshops in meetings, making other members of the team want to get involved, so we expanded the workshops to a company-wide challenge.

Different things we’ve made so far;

Facebook & Renaissance
McDonald's & Art Nouveau
Mobile OS & 90s Websites
Twitter & Neumorphism
A Cash Machine & De Stijl
Poster & Swiss Style
Google & Post-Modern
Notes App & For Toddlers
Festival Poster & Deliberately Inaccessible
Art Deco & e-commerce site
A merch shirt for your favourite place & using only your favourite colour

What did we learn

After about 6 weeks of working on our UI, one of our team had the idea that the prompts could be developed from just art styles into something more UX focused. The idea we had was to also have user groups or UX issues as our prompts. These could be something like “for children”, “for the visually impaired”, or something sillier “with no text at all”. These turned out to be excellent prompts too. Rather than getting us to focus on the visual design of our work, these UX prompts had us thinking of our designs in a different way. We had to keep the user or the issue in mind and make quick decisions to serve their needs. These prompts also ended up being some of the most fun ones!

Sharing it with the world

The more workshops we did, the more we realised how great it would be to put all of the products to redesign and the styles we had into a home-made generator where we could randomly get a prompt each week. Our designer Rachel Brockbank spent some time working on collecting 100-ish products, features and graphics to be redesigned or designed, and a bunch of different style prompts that were UI focused, UX focused and more general visual design-focused.

We starting off with just the generator and a ‘new prompt’ button, but we realised that if we wanted to share our workshop idea and prompt generator with the world it would need a bit more context.

We set about making a little website to house our generator — check it out for yourself!

Wonderful Weekly Workshop

We love these workshops, and we’d love for you to love them too! You can do them with your whole team or just on your own to test your design skills. If you do give it a go, please do let us know and share your wonderful designs with us!

If you enjoyed this article, you may also like…

📄 How come everybody loves to hate self-checkouts?
📄 So you’ve lost your design mojo? Well here’s how to get it back!
📄 Why does design for children’s websites have to be so chaotic?

Before you go…

👏 Share this article to help others find it!
💬 If you have something to say, drop us a line on Twitter: @InktrapDesign.
📝 Sign up to our design newsletter Minimum Viable Publication, published every Tuesday at 1 pm.

After Lockdown

Jon Barker — Thu, 07 May 2020 13:26:48 +0000

afterlockdown.me. We’ve collected post-quarantine aspirations from around the globe. What will you do after lockdown?

Why?

The COVID-19 pandemic has changed almost everything about our daily lives. The way we work, the way we commute and the way we communicate. It's difficult to look away from the daily updates and make blind hopeful stabs at when we'll be allowed out again.

Despite this people are still looking for a way to find a silver lining during the lockdown. Nature is creeping back into cities, and the lockdown may have inadvertently kick-started a shift in how we view the daily commute and 9-5 office hours. Previously overlooked professions are being recognised for the essential duties they perform daily.

One benefit that we've noticed is that we start to realise what we miss. What is important to us. What are the things that make us happy? We begin planning what we'd do after the quarantine and start to look upon things we'd previously taken for granted with a new sense of reverence.

That's when we decided we'd create a kind of memorial to these dreams. A place to look back on post-lockdown and remind ourselves of exactly what people found important when we were forced inside.

The Goal

The goal was simple enough. A website where people from all over can catalogue their goals. A kind of interactive digital museum for the future.

This was simple enough to achieve. We used Laravel to spin up an application quickly and put together a simple interface.

The real discovery for us though actually laid outside the technology.

The Process

We decided that as we only had a small amount of downtime at the office we would have to fit the development into a 3-day gap in our schedules.

In the office, we're used to sitting next to each other. Able to quickly get an opinion on a design or approach to a technical problem.

We recreated this in Google Meet. Scheduling a meeting and then leaving the room open for the day. The window permanently in the corner. It was the most office like environment we could come up with, and it worked surprisingly well.

At 12 a founder would join us for a brief update on how the project was going. But we would remain in the chat once the stand up was done.

We were once again able to brainstorm, and talk fluently where previously we were chatting in Slack, scheduling a call, closing it... repeat. We could discuss things as and when needed. And even get across those "aha" moments before they slipped our mind.

We also used Figma to work collaboratively on the design. Again, being able to discuss things immediately was a great benefit.

Working this way isn't the perfect fit for every project. For such a small side-project it was surprisingly effective. It was the closest semblance to our previous environment we could create.

Conclusion

Things aren't normal right now, and may not be for a while longer. But the constants that mattered before still matter. We're thankful that our workplace still understands the importance of allowing their developers to experiment in their own way. Where some agencies would have placed their employees on an unimportant task during downtime we were allowed to work on what we thought would be fun.

We also found that recreating the office virtually is actually quite productive (though obviously not a fit for every person and every project).

In the end, we surprisingly think that after lockdown we want to get back into the office.

Refactoring CSS

Jon Barker — Thu, 26 Sep 2019 09:16:57 +0000

Refactoring CSS

What to keep in mind when thinking about refactoring your CSS

Photo by Clem Onojeghuo on Unsplash

As developers, we work in an industry that has a luxury not afforded to many others. We can edit things that have already been published.

In many other industries retroactively changing things is incredibly difficult. A writer can’t take their book off the shelves and rework a sentence. An artist can’t remove layers of paint to improve the layer beneath, and a construction company can’t build a new floor off-site and slot it back in when it’s ready.

Us developers? We can iterate internally on the design, on the frontend or backend, and then continue to push changes once the product is live.

This is a very good thing.

Because, no matter how careful we may be, we’re almost certainly going to come across code that we look at and think, “this could be better.” At which point you and your team might decide it’s time to improve it.

It’s worth noting…

“An ounce of prevention is worth a pound of cure.” — Benjamin Franklin

Even though the idea of a refactor sits over most mature products it doesn’t mean you should code with a we’ll-rewrite-it-later-anyway mindset.

Having a style guide, an outline of the project, a plan for approaching it, a proper directory structure, and naming convention are still important. Having these in place is what stops a quick refactor from becoming a complete overhaul.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? “— Brian Kernighan, The Elements of Programming Style

Refactoring can be difficult and is often tagged on as kind of an afterthought. The truth is, just like accessibility and responsiveness, it should be planned and approached as part of the main work. Not an extension to the project.

Why would I have to refactor?

A CSS Mess. A CESS, if you will.

As we mentioned at the beginning, we can constantly iterate on the work we do. Because of this, our job continues after pushing to production, and the codebase can grow larger and larger. We can keep the code as clean as possible along the way, but with enough “quick changes”, pulls and merges, things can get messy.

Let’s take the following fictitious example:

A website has a blog section with a nice card layout. The CSS (if using BEM )might look something like this:

/* _blog-post.scss */
.blog-post {}
.blog-post__header {}
.blog-post__title {}
.blog-post__image {}
.blog-post__footer {}

The product changes and you’re asked to add a news section. It has a similar layout and style. You don’t want to give a news-article the same class as a blog post. So you make another file:

/* _news-article.scss */
.news-article {}
.news-article__header {}
.news-article__title {}
.news-article__image {}
.news-article__footer {}

You could be asked for a similar events section, but let’s leave it as it is. Now we have the problem of unnecessary duplicate code. What we probably want is to remove the above files and have something more like:

/* _post.scss */
.post {
    &__header {}
    &__title {}
    &__image {}
    &__footer{}

    &.post--blog {  
        /* Modifier stuff here */  
    }  
}

But of course, CSS is finicky and operates globally. When a new developer comes to this CSS they might be scared of changing it for fear of it breaking something elsewhere. On top of that, they might be working to a deadline, or maybe they’ll say “I’ll come back to this later”, but never will.

These little things add up over time and might result in your team deciding on a refactor.

When and when not to refactor

Maybe you’re thinking, why would I even touch this if it works? And that’s a very important and necessary question because you might not need to. The following isn’t an exhaustive list, but just an idea of things that may sway you one way or the other.

When it might be time to refactor

Your CSS is excessively large.
Hinders performance in some way (large load time, layout breaks in specific use cases)
Developers spend time working around the code, not with it.
You want to increase the readability for newcomers.
You work in a very large team and refactoring now means you’re saving a little time for a lot of people.
A specific issue has been raised by multiple people.
The refactoring will be quick.

When it might not be necessary

A rewrite or re-design is coming up, and it will be easier to write from scratch.
The CSS “looks bad”, but no developer has had an issue with it. And no user has reported any
The CSS is bad but belongs to an element or component that won’t be touched. Take for example a footer which isn’t going to change. If a developer had some initial problems, but it’s finished and works, it might be worth focusing your attention on a different part of the site.

Of course, whether something is worthy of a refactor is your choice. The above are just indicators I’ve learned of. So you decide it’s time, now what?

Refactoring “on the move”

This should be your first port of call. These are small pieces of tidying up that are more relaxed and less arduous than a full-on refactor.

It involves going over your .css or .scss files and combing them for classes that hold the same style declarations or have declarations that override each other. You should add comments to rules that don’t make immediate sense or seem to be unused. For instance, the class might not appear in the HTML but is added later by JavaScript. For example:

.faq {  
     &.is-expanded {  
        /* Toggled when user clicks on element */  
    }  
}

Of course, doing this manually might take a while, so use a Linter. You can tweak your config and be warned upfront about things like duplicate declarations or empty selectors.

You can also get some valuable information about your CSS using CSS Stats. This site can provide valuable information about the inline and linked CSS you’re using. You can get size comparisons to popular libraries. Declaration counts for layout, spacing etc, it shows a specificity graph… And the number of unique declarations for things like colour or font sizes.

Take the stats with a grain of salt, and have a general idea of the codebase you’re working on. Because having 40 unique colour declarations might seem like a lot for a standard marketing site, but for online clothes stores with colour swatches these results wouldn’t be so surprising.

When used properly the stats can be very insightful and can be used to weed out unnecessary rules. If your design system lists 7 different sizes in its type scale and you have 30+, maybe it’s time to refactor those declarations into a single class or remove the declarations that are never actually applied.

The “component refactor”

This is the refactor that is done with one specific element or component in mind. For example, you’ve decided to tackle the header because multiple devs have had problems adding to it or modifying it.

The thought of diving straight in and making everything better for a lot of people can be motivating. But slow down and ask yourself or amongst your team the following questions:

**What really needs to be refactored?**

Let’s imagine we have a large messy footer that has some unused CSS and a bunch of hacks.

It might seem like an ideal candidate, but if it’s a part of the site that works, no users have reported a problem and it isn’t due to be updated for a while it can most likely be pushed to the back of the queue.

Maybe you have a nav that has many different variations or states might be better as a target. Maybe it’s snowballing and developers keep adding more classes with more specific rules to override it’s already specific selectors. Or perhaps we know that the client wants to add more states in a coming update. Or, you’ve finally dropped support for an older browser and you can use newer features like flexbox and rewrite the hacky float filled CSS from before.

Is the refactor short enough?

A refactor of a whole page might take longer than you think. You might be well served to set a smaller goal. Rather than tackling a whole page, how about just the buttons, or forms? Having smaller targets means you can demo the improvement more quickly, and be back on other projects/dev work faster than if you were tackling something huge like the home page. You should always have the end goal in sight. Refactor, move on, repeat.

Where shall I do my “refactoring”?

Basically, anywhere but the project it came from. CodePen, jsFiddle, a playground HTML file in your dev environment.

The main point is that it should be built away from your old stale codebase, though could import the grid if absolutely necessary. Refactoring in this way means that we rework our component away from all the conflicts or overwrites that were causing it to be messy in the first place. We can build it and test it in a new sterile environment, knowing that when it’s complete and reincorporated into the site we can identify more easily where the conflicts come in.

How should I implement the refactored code?

In Isolation 👀

Once this is done, you can swap out your old nav for the new one. At this point, there will likely be some conflicts with the old CSS. So what do we do?

We need need to write some hacky CSS now to help preserve our sanity later. This sounds counterproductive, but it’s actually a good strategy when refactoring. We can isolate, signpost and write this “quick fix” CSS until our refactored component looks as it should, then as the old CSS is removed and these conflicts disappear we can remove these hacks. Let’s look at a practical example with a nav.

Step 1: We’ve refactored the nav in isolation. It follows all best practices and is ready to replace the old clunky one. We swap out the HTML and import our new .scss file.
Step 2: We’ve brought it in, but it doesn’t look right. The styling for the colour and font size are off because of the specificity of some older badly written code.

Code below:

/* _links.scss (old) */

    header > nav li a {  
    color: blue;  
    display: inline-block;  
    padding: 0 0 0 10px;  
    font-size: 12px;
}


/* _new-nav.scss (new) */

.nav__link {  
    padding-left: 10px;  
    color: red;  
    font-size: 14px;  
}

Step 3: We code to fix the problem, but we do so away from our clean CSS. In a well-commented, appropriately named file reserved solely for “bad” code (fixes.scss, hacks.scss, shame.scss or temporary.scss would all work).

Code below:

/* _fixes.scss *//*  
    Add !important declarations to the .nav__link class because more specific code from _links.scss is overwriting the colour and font-size.  
*/

.nav__link {  
    color: red !important;  
    font-size: 14px !important;  
}

Step 4: Now we “attack” the bad CSS. We go in and remove the old stale CSS that was conflicting with our shiny new nav.
Step 5: Now we can remove our fixes CSS for that specific conflict.
Step 6: Repeat until old CSS and hacky CSS are removed.
Step 7: Marvel at the beauty you have created.

Harry Roberts explains this approach thoroughly in his talk from the WeAreDeveloper’s Conference in 2017. https://youtu.be/fvTryZjGyg8

Conclusion

The need for a refactor can be kept at bay by improving as you are going along and introducing useful build tools like linters, or products like CSS stats into your workflow. But when and if a refactor is necessary, it should be approached methodically and as carefully planned out and iterated on as the actual product itself. Hopefully, the information above can help you better prepare.

Feel differently? Have anything to add, agree, disagree? If you’ve got any feedback we’d love to hear from you — please leave a comment here, or drop us a line on Twitter. We’re @InktrapDesign.

5 ways learning to program is like learning a foreign language

Jon Barker — Wed, 11 Sep 2019 11:26:04 +0000

Summer is coming to an end, and a few members of the Inktrap team are trying to up their language game as their final holidays approach. Spanish, French, German and Arabic are being thrown around the office. But they’re not the only language we can hear in the room. What about JavaScript and PHP?

We started to wonder how similar learning a programming language is to a spoken language. Turns out, in our opinion, the process is pretty similar.

You learn the concepts first, not the specifics

Learning your first foreign language is difficult. It’s arguable that you actually learn more about your own language at this stage. Your native language is innate, you don’t really think about what you’re saying, it just comes out.

Then you begin to question yourself and end up asking, “why are we on a bus, but in a car?”. It feels like you’re losing your sanity. You question everything you’re saying in both your native and target language.

Programming is just the same, it’s less about the specifics and more about knowing what constructs are universal across multiple languages. Once these are understood, the knowledge is transferable.

In spoken languages, it’s things like pronouns, verbs, adverbs, and adjectives. In programming, it’s variables, conditionals, while loops and classes.

“The more you know, the more you know you don’t know.” — Aristotle

As you learn more and more you’ll find that you need to put in more effort to see an increase in your proficiency. Once the building blocks are out of the way you really need to dig deep to understand the nitty-gritty stuff.

With a spoken language, you start to see how much is really ahead of you when you try to do something beyond ordering a coffee. You bump into a native speaker and it dawns on you how many words you can’t recall immediately. Or how often you use incorrect grammar.

With any kind of development, you realise how much there is to learn when you go from building a small side project or website to working on a fully-fledged application with users and testing and feedback.

It may sometimes seem like you’re coming to terms with a concept, only for it to fork off into two additional things you need to learn. The most important thing is to not be dissuaded. As the French would say, “petit à petit l’oiseau fait son nid”. Or in English, “little by little, the bird makes its nest”.

An IDE or good code editor will help

Creating websites or software in a helpful IDE (Integrated Development Environment, like Webstorm) is like speaking in your target language with an extremely useful assistant on hand.
They will show you where things are and provide you with shortcuts. If you type some code and make an error (kind of like preparing a speech), they’ll point it out and say “hey, watch out for that.”

You’ll be able to see your mistakes and make note of the ones you make the most often. They’ll help you clean up your code or if you were learning a language — your sentences, and point to the function (verb) you’re looking for.

You wouldn’t disregard help from a friend, don’t shun help from your computer.

You learn by doing, not by learning

It’s obvious that the key to learning a spoken language is by getting out there and practising. The same applies to learning a programming language. You will never fully understand all the little quirks of either if you don’t get out there and start making something with them.

You can’t read JavaScript: The Good Parts and expect to be able to immediately write something as renowned as Vue.js. You can’t read about a language’s grammar and travel to its respective country and expect to hold a conversation straight off the plane.

Learning either is a practical, rather than an academic endeavour.

In the end, you’re still crafting a story.

So what is the purpose of learning all these words and structures and concepts anyway? It’s not just to proudly boast that you’ve learnt something well enough to be proficient in it.

In both cases, it’s to craft stories. It’s about making something or saying something that’s relatable or enjoyable for the person on the receiving end.

This is more apparent of course with spoken languages, but the end goal with programming or web development is the same. You’re not just storing cookies, you’re giving them an experience. Maybe you’re creating an enjoyable onboarding flow, or making a difficult process easier, as we did with current client Farillio, that makes handling legal documents easier.

All in all, the end result, as usual, is a connection with a person.
Feel differently? Have anything to add, or just want to tell us about your awesome language skills? If you’ve got any feedback we’d love to hear from you — please leave a comment here, or drop us a line on Twitter. We’re @InktrapDesign.

Starting a new job as a self-taught developer

Jon Barker — Mon, 08 Apr 2019 17:05:50 +0000

Entering the world of web development as a self-taught professional is pretty scary. Mostly because web development isn’t a job that easily instils confidence.

For one, your self-assurance can be shaken by a seemingly untraceable bug or typo. This means your first few years of learning are plagued by a constant hum of “am I doing this right?”, which is occasionally broken by sporadic bouts of “I am the best” plunging right back to, “I know nothing.” For these reasons, accepting a job in an agency (or anywhere, really) can feel daunting.

You’re in a place where you feel as though your new colleagues know everything, whilst you’re still uncertain if you could write the DOCTYPE properly without your editor doing it for you. In your mind, your use of StackOverflow is a weakness. If you were as good as your peers you’d have all that knowledge at your fingertips. Just like they do… right?

Of course not. And, while these feelings of inadequacy can seem overwhelming, it’s important to face them head on and remind yourself that, although these emotions are valid, they needn’t generate the kind of angst they’re capable of.

Keep the following in mind so you can walk through the door excited for a realm of new possibilities:

You were hired for a reason

At some point, before you got the call or the e-mail offering you the position, the team sat around as a whole and decided that your competencies and attitude meant that you’re a good fit for the role.

They did this knowing everything that you had told them during the interview. Unless you told an enormous lie, they were fully aware of your current skillset. They were also aware of the skills that you’re looking to improve and felt strongly that you’d be able to pick up any necessary skills during your employment.

They have met you. They know what you’re capable of. They know what kind of person they want in this role. Trust in their judgement.

You should be proud of how far you’ve come

You have, through your own initiative, learnt a relatively complex range of skills to the point that a group of people have decided to offer you a position within their company.

The invitation to interview was not something that fell into your lap by accident. You earned the opportunity to be there. Believe it or not, this is a feat that should be acknowledged. (Mostly by you, but external acknowledgement is always nice too).

You have things to learn and many (many) problems to solve

You do not, and cannot, know everything. The same goes for your new found colleagues. You will see them looking at StackOverflow. You’ll see them watching tutorials. You’ll ask them a question, and they won’t know the answer. What separates a good developer from an average one is that a good developer is always ready to find a solution.

You should be comfortable with the idea of saying “I don’t know, but I’ll find out.” Learning is fun. It helps us grow whether personally or professionally, and we get to experience that little rush when a solution is found to a problem that previously seemed unsolvable. You’re not going to know the answer to a lot of questions throughout your career, and you should embrace it.

You will be criticised (constructively, of course)

At some point, the work you do will be under review. Maybe you made a mistake the team is trying to fix, maybe it’s a run-of-the-mill code review, or maybe you’ve just asked a colleague for help and they’ve spotted something while looking at your screen.

In one way or another, you might get told that something you’ve done is wrong, or could be done another way. A better way! That’s right, you’ve done something incorrectly, or not optimally.

You shouldn’t fret. It’s easy to get defensive when feedback is being given, but good feedback is never about you personally and is given out with good intentions. Take the information, learn from it, and try to implement the suggested change next time.

It’s in their interest to take care of you

Any sensible business has a system for the induction of their new employees. You wouldn’t be able to break anything crucial, even if you wanted to.

At Inktrap, my first day included a relaxed introduction to the team, getting set up on the computer and dealing with any paperwork.

Your induction will likely follow a similar pattern. When you move on to the development side of things, you might work on some internal projects before moving to client work. Your new employer has no interest in making this difficult for you.

Don’t get rid of all the doubt

You should acknowledge your hard work, and feel a sense of pride when you think of all you’ve taught yourself. However, we don’t want the pendulum to swing too far to the other side.

We want doubt. Doubt makes us question whether our approach is the right one. It makes us ask for help, which in turn makes us grow and adds to our understanding of how things work. It makes us better developers.

Ultimately, when walking through those doors on your first day it’s essential to have faith in yourself. It’s also important to have faith in those who hired you, and understand that they know why they offered you the position. Take pride in how much you have learnt and be confident in your ability to learn more.

In short, you’ll be fine.

Got any other tips to get over those first day jitters? How have you helped your junior employees settle in? If you’ve got any advice we’d love to hear from you — please leave a comment here, or drop us a line on Twitter, we’re @InktrapDesign.