Forem: Thomas Langdon

How To Stay Motivated While Learning To Code

Thomas Langdon — Fri, 22 Nov 2019 21:52:43 +0000

We’ve all experienced it at some point. Whether it was while learning to code, or during another task, whatever it is, it sucks. This scenario may sound familiar to you: filled with the desire to learn to code, be it for a career or a hobby, you sit down, do your research, maybe sign up to a few courses on Udemy and get stuck in.

Over the next few nights, you are reading up on concepts, getting stuck into projects and making serious progress. Then you start experiencing burnout, you’ve missed one too many trips out with your friends, you’ve been working a 9:00–5:00 every day and on top of that, housework and learning you haven’t had any time to unwind. So you take a couple of nights off, those couple of nights become a couple of weeks, then a couple of months.

If this is sounding familiar you aren’t alone, burnout and loss of motivation are a real issue, especially with something like learning a skill as in-depth as programming. The good news is, there are actionable steps that can be taken to make the whole process a little easier to handle.

#1 Set Proper Goals

No “Learn to code” doesn’t count. For a goal to be worth anything it needs three important components, and this applies to everything not just learning to code. The first is measurability, there is no use setting a goal if you can’t determine when you have achieved it. A much better goal than “Learn to code” is “Complete a course for Angular”.
By setting measurable goals you can determine when you have reached them, and then set a new one, if your goal is too vague you will never hit it. Secondly, your goals should have specific deadlines, if the goal is too open-ended it can be difficult to maintain the focus required to reach them.

If your goal is “Complete a course for Angular” you can tell yourself you’ll get to it eventually. If your goal is “Complete a course for Angular in 6 weeks” then the deadline will give you an extra push to finish the work. Finally, the goal needs to be realistically attainable. There is no use setting yourself a goal if you can’t achieve it, which leads us to…

#2 Consistency Is Key

I’m sure you’ve heard the phrase “Slow and steady wins the race”, the same rules apply here. All too often, people will decide to learn to code and stay up late into the night, and progress is fast because of it. But it doesn’t last long, this leads to the problems we talked about at the beginning of the article, namely burnout.

It is much more important to make slow but consistent progress towards your goals, the quick, but short-lived bursts. Set aside 30 minutes to an hour to do a little bit of work towards your goals every day, and with time you will see improvement.

#3 Motivation Gets You Started, Willpower Keeps You Going

Truth be told, there is no magic pill that will make it easy all the time, now trick that will make it so you're always eager to learn. There will be days you want to do nothing less, there will be times where all the effort doesn't seem worth it to reach your goals, but if you keep at it then it will be in the end, and you will achieve your goals.

#4 Get Support From Your Peers

Never underestimate the power of community spirit, and the developer community has some of the best community spirit of any I have been a part of. I have already spoken about the benefits of peer programming, and this is just one of the many ways you can take advantage of, and contribute to, the developer community. There are many resources to read, discussion to be had and courses to follow.

Two Developers — One Laptop: Why you should be peer programming

Thomas Langdon — Thu, 21 Nov 2019 20:53:51 +0000

I've briefly covered this story before in my article: 11 Things Every Aspiring Developer Needs To Know, but it was such a huge part of my early growth as a developer that I felt like it warranted telling properly. It's a story talking to the benefits of peer programming, and how when used correctly it can be a huge boost to your learning, especially as a new developer.

The Story

I was lucky enough that in my last year at university, a close friend and I both interviewed at the same small company and we were both given a position as junior developers starting at the same time. Even just starting a new job with someone on the same level as you, let alone a close friend, is going to do wonders for your growth. Having someone to bounce concepts off, and go over things you don't understand, as well as doing the same for them is a crucial tool as a new developer. But our position ended up being somewhat unique.

I was the second of the two interviews at 5:30 PM on a Friday, and we started 9:00 AM the next Monday. The thing is, they hadn't originally planned on hiring both of us, which meant when we arrived Monday morning there was only one laptop. So they showed us around the office, where the toilets were, how to work the coffee machine and all the other important parts. Then we sat down at the one desk, with one laptop, and just started work.

We started by looking at the product, getting familiar with the stack and the different technologies, getting used to some of the conventions, and as the days turned into weeks we were still working from one laptop. Seven and a half hours a day, 5 days a week of peer programming, and those 2 months were some of the fastest growth I experienced as a developer.

Why Peer Program?

Now I understand that wasn't purely down to the fact that I was peer programming, I had just started my first professional development position and as a result, had access to all the resources that come with it. All the people with experience, the structure that comes with the project workflow, it all helped, but I firmly believe that peer programming played a huge part in how much I progressed in those two months.

Don't get me wrong, I am not advocating that all new developers should be chained to another new start for seven and a half hours a day, there are definitely diminishing returns, especially when it's always with the same person. I would, however, say that it is a very important part of any new developers' training, so much so that when we were reviewing our new hire policies recently, it was my number one contribution to the discussion.

I understand that not everyone is lucky enough to be starting alongside another developer, especially one they already know and like, but you don't even need to be physically with the person you are peer programming with to get the benefit. A voice call and a screen share are more than enough to get two, or even more, developers to work together and help each other learn.

Picking a partner

When looking for a partner, I think the number one consideration should be to make sure you are of a similar skill level, this way you can learn from each other. If you aren't on the same page it becomes more like tutoring, which definitely has its merits, but the give and take of peer programming will benefit both parties.

Secondly, it's obviously useful if you are both working with the same or similar stacks, but the principles are often similar enough between certain technologies that it's not a requirement. If you can find someone of a similar skill level, working with the same technologies who is willing to work with you on a project or two, or even just a couple of sessions, you're onto a winner. Why don't you see if there is anyone interested in the discussion below?

11 Things Every Aspiring Developer Needs To Know

Thomas Langdon — Wed, 20 Nov 2019 20:49:47 +0000

My first few forays into the world of programming were confusing, frustrating and some of the most daunting experiences I’ve had. It can seem like everyone around you has a vast fountain of knowledge and started writing code when they were 8 so you have no hope of ever being as good as them. The truth is that almost everyone experiences this and with enough time people will look at you in the same way.

The points outlined below are a list of concepts I wish I had grasped early on in my developing days. I would have saved countless hours of wasted time and I want to make sure you avoid these pitfalls in your endeavour to become a better developer.

#1 Perfection is the enemy of progress

Sure, everyone wishes their code could be perfect, but labouring over every line of code until it’s as efficient as possible and perfectly written is going to severely slow your progress. The concept of an MVP in programming is a Minimum Viable Product. Whatever it is you are making to teach yourself a new concept, get it working in the most basic capacity, learn what you wanted to from the exercise and then if required come back and refactor your code. If not, move on and start learning something else.

#2 Don’t let changes pile up

Two agile development tenants come to mind here. The first is to develop small, incremental releases and iterate, The second is to test early and often. One of the biggest mistakes I made when I started developing would be to start a new project, write 200 lines of code, and only then spin it up for the first time.

The result would be 4 or 5 different errors all compounding and obscuring each other, making it much harder to find the problems. If you test early and often while incrementally developing small pieces of functionality it will be noticeably easier to debug and test.

#3 ‘Cheating’ is not only normal but expected

I see this with a lot of the new starters at my current company. When they run across an issue, instead of googling the problem they want to get to the root of the issue themselves so that they can learn from the experience. While this can be a good approach to simple problems, and you shouldn’t just immediately turn to google every time an error pops up, more complex issues should be researched. I haven’t met a single developer who doesn’t use google frequently throughout their day, even at the upper end of the experience scale.

#4 A degree will get you in the door, knowledge will get you a job

I have been involved in the hiring process a few times when looking at new developers for my current company. and while a degree is an extra point against your name, it is by no means the be-all and end-all of the hiring process. A candidate with a strong portfolio or even just a basic level of knowledge and a willingness to learn is going to rank much higher than someone with a degree but the wrong attitude. That being said, if you are in the position to get a degree it is a fantastic way to gain the knowledge in a structured and guided environment.

#5 Knowledge of concepts is vastly more important than syntax memorisation

Too many new developers will spend forever trying to memorise how to construct certain elements and not enough time on the big picture. Knowing what to use and when to use it is 90% of development. Once you have that you can google the exact syntax, or even better use a snippet manager.

#6 Pair programming is like steroids for development learning

I understand that not everyone can physically sit down next to someone and collaborate but it is the most powerful tool I have found for new developers. When I started my first full-time developer position I was lucky enough to be doing so alongside a friend from university, and due to a combination of lack of organization and lack of company resources, for the first two months at the position, we only had one laptop between us.

This sounds like a terrible idea as it would immediately cut any productivity in half right? That wasn't my experience, those two months were probably some of the biggest periods of growth I ever experienced. It was often the case that one of us would get a concept better than the other and help the other figure out the missing pieces and everything just came together. So much so that I have suggested the concept be trialled again if we ever get two new starters at a similar time.

#7 Finish what you started

My early days were riddled with jumping from one idea to the next, trying out this new language, and then the next. If you start a project to create something instead of just as a learning exercise, put in the time to finish it. By starting a new project every few days I got good at starting projects and doing the same few tasks, but it took a long time before I learned how to polish a site, or how to release something to production and all the tasks that come with that. If you are always working on starting things, you’ll never learn to finish them.

#8 Be wary of cutting edge technologies

Being up to date and using new technologies is important, but once you make your way to the very bleeding edge it’s like the wild west for a new developer. There is often very little documentation on how to achieve things, and if you are working with release candidate builds there will often be bugs that just further complicate things. Working with bleeding edge technologies is a lot of fun and can be a great way to drive your learning, but as a new developer, it’s easier to walk where others have been before.

#9 Conventions are important, but you can’t always have your way

Naming conventions and best practices are important, and when you are working in your personal projects these can be whatever you want, but in a professional environment these will often already be determined and you will be at the mercy of the team. It’s important that no matter how much you disagree with the naming conventions, you follow the rules that have already been set out. If you do disagree with the standards, however, this shouldn’t stop you from making suggestions for future implementations and bring the standards up for discussion.

#10 You will hate code you wrote 6 months, or even 6 days ago

I have never met a developer who can consistently look back 6 months and be happy with their code output. As a developer, you should always be learning and improving. After a big revelation (like how you should be writing reusable code) and a new perspective, you will look back on your previous code and cringe at how you didn’t do this one thing quite right. This is normal and a sign that you are improving.

#11 Perhaps most importantly, just get stuck in

Too often new developers will get caught up in reading about a new technology or an interesting design pattern, but truth be told the best way to learn programming is to write something! So pick up a simple project or try and complete a coding challenge, and it will get easier and easier.

Why You Aren’t Writing Enough Reusable Code And 5 Ways To Fix It

Thomas Langdon — Tue, 19 Nov 2019 21:31:23 +0000

Reusable code is the holy grail of development. If you can write something once and use it over and over again, you’ve just saved yourself valuable time. But complicated, single use spaghetti code seems to be the norm, especially among newer, inexperienced or self-taught developers.

Making the switch to writing reusable code will not only save you countless hours of rewriting similar blocks of code, it will revolutionise the way you think about application structure and you will be outputting higher quality, easier to understand code.

What Is Reusable Code?

Reusable code is exactly what it sounds like, it’s code you can use more than once. This can mean a function you use more than once in the same application, or a block of code you use in multiple different applications, it just has to avoid being over-complicated and bespoke.

How Do I Write Reusable Code?

Making the switch to writing reusable code can be daunting at first, it requires a shift in perspective and you often have to change the way you handle application structure. Stick with the steps laid out below and I promise when you look back on the code you used to write you will wonder how you coped.

#1 Make all of your functions single purpose

We are all guilty of breaking this rule, you know what I mean. We have all written 300 line long functions that perform 10 different separate actions, and sure it works, but what happens when you then need to perform just one of those 10 actions? Now you are needlessly recreating functionality. Instead, you should split each of those 10 actions into their own function and call those functions from the original.

Even if you never plan on reusing the functionality, giving each function a single purpose creates inherently better code. It makes it easier to debug, easier to unit test and easier to read. Speaking of unit tests…

#2 Test Driven Development

This has always been somewhat of a sore-point for a lot of developers, myself included, and I personally don’t practise what I preach in this regard but if you are struggling this can give you a real boost. Test driven development in a nutshell is writing a unit test that would return a successful result for the function you want to create, and then creating the function to pass the test.

I wont go into the pros and cons of test driven development here, that’s an article for another time, but this style of development is great at leading you to creating single purpose functions. Test for the outcome you want, and then create that outcome.

#3 Write DRY code

This one is nice and simple, dry code stands for Don’t Repeat Yourself. The whole point of reusable code is that you don’t have to write the same, or similar things twice. If you are often repeating yourself, chances are the code you wrote in the first place wasn’t reusable enough.

Instead of repeating yourself with a slightly altered bit of code, look back at the original and work out what you could do to make it work for both situations. Often this will take you slightly longer than rewriting the code, but it means that if you need to use it again, chances are you wont have to write anything. Possibly even more importantly, if you need to make a change to how the code works, you now only have to make the change in one place. If your code is repeated, you have a lot of changes to make, some of which you might miss.

#4 Use a Snippet Manager

The points so far have focused on how to reuse code from within the same application, but what about reusing code across applications? I’m sure you have had a piece of code you know you have written before, but you can’t find which application you wrote it in and so you give up and write it again.

This problem can be avoided with a snippet manager, but there is a lot more information on what these are and how to choose the right one for you in my earlier post: 5 Code Snippet Managers That Will Change The Way You Write Code.

Something unexpected I found when I started using a snippet manager was that the code I wrote ended up being better quality. Knowing that I was going to want to save the section of code I was writing into my library, I spent longer making it cleaner, more efficient and more reusable.

#5 Keep The Business Logic Separate

This is kind of the same point as #1 but I see it enough that it warrants it’s own point. All business logic, whether that’s API controllers, Database calls or class declaration, should be separate form the bulk of your code. Just like with the first point, if you need to use any of the functionality tied in with your business logic, your going to have to rewrite or re-purpose it, and that will only lead to trouble.

5 Code Snippet Managers That Will Change The Way You Write Code

Thomas Langdon — Tue, 19 Nov 2019 10:56:30 +0000

We all know the feeling, you are working on a new app and you need to do something you’ve already done 100 times before, but you can’t quite remember how you did it. You go and dig through your previous app for the snippet of code you need, but you can’t find it in there. Maybe it’s in this site, or the other one?

20 minutes of searching later and you finally find what your looking for but that was 20 minutes you could have used for something more productive if you had a code snippet manager.

What Is A Code Snippet Manager?

Code snippet managers are the solution to reusable code. They let you save a library of commonly used snippets of code, either in the cloud or locally on your machine, and keeps them organised and ready to use. The good ones will have a mini editor with proper syntax highlighting and support for multiple languages, the REALLY good ones will let you group snippets, link them together and share them with your friends/co-workers.

Whichever option is right for you, a snippet manager should save you time, enable proper re-using of code and make sure you never lose an important bit of code again. Have a look below at the five best options I found and supercharge your coding workflow.

#1 Best All-Round: 3Cols

One of the best features of 3Cols is it’s fantastic built-in editor

Why waste your time and put the best option last in an article all about how to save you time. 3Cols is by far the best option I have found and is in-fact the reason I created this list when I found a post about it here on Reddit. They claimed to be the best option in the space, and I wanted to find out for myself. But the claim seems to hold up.

Pros:

Unlimited private snippets for free
Best categorisation options on the list
Fully featured editor
Lighting fast
Works on web or installed on almost any platform

Cons

No integration with browsers or IDE (yet)
Sharing requires a premium subscription ($1.69 a month)

It really is no competition here, there is no other option that stores your snippets privately on the cloud, works both locally and on the web and all for free. Not only that but if you do end up sharing your snippets (I fully recommend creating a collaborative board between you and your developer friends) it costs only $1.69 a month — over 3 times cheaper than the next cheapest option. The only drawback here is their lack of integration with any IDE’s or, less importantly, a browser extension to easily save snippets, but according to the Reddit post I mentioned, both of these features are coming in the future, so watch this space!

#2 Most Integrated: Your IDE!

The availability of visual studio’s snippet manager struggles to make up for the clunky interface

If you are looking for something easy to use with minimal setup then most IDE’s worth their salt have a simple snippet manager built in, or at least have extensions to do so.

Pros:

Minimal Setup
Never have to leave your IDE
Always free

Cons:

Very Limited Features
Often not backed up on the cloud
Interfaces can be somewhat slow/clunky

Although they are easy to set up and use they don’t come without drawbacks and they probably shouldn’t be used as much more than a first step into the world of snippet managers. A few of the options on this list have their own IDE extensions to offer a similar feature anyway.

#3 Best Extensibility: Snipit

Great integration and favourites/tags are the stand out features of Snipit

If you want the luxury of never having to leave your IDE as with the option above, but you also want cloud backups, a richer feature set and a browser extension to easily save snippets you find around the web then Snipit is the option for you.

Pros:

VS Code extension for seamless integration
Multiple browser extensions to easily save snippets
Unlimited public snippets for free
Favourites and tags make finding specific snippets easier

Cons:

Creating private snippets requires premium (€7.00 per month)
Only has one level of categorisation
Layout isn’t very responsive on smaller screens

Overall all Snipit is a good choice with excellent integration, but if you care about keeping your snippets private then you need to be ready to cough up the hefty €7.00 a month required to do so and to organise them all with only one level of grouping.

#4 Biggest Name: GitHub Gists

The backing of a big name can only go so far to help you ignore how painfully slow Gists are to navigate

Sometimes having the reliability that comes with a company like GitHub is very important, and the version control and API that come with Gists are an excellent addition but you had better be prepared to wait for them.

Pros:

Backed by GitHub so stability and reliability aren’t a worry
Version control can be useful in certain conditions
API access gives you a whole new way of working with your snippets

Cons:

Painfully slow to navigate between snippets with a fill page load each
Very Limited Categorisation
Sharing is very clunky

I feel like the only thing holding Gists back from being a candidate for my top pick is how slow it is to move between your snippets. The fact that each snippet requires a full page load to view is a deal breaker for me, and the fact that sharing private Gists requires a link with no sort of browse-able repository is another nail in the coffin.

#5 Best Local App: Snippets Lab

The fantastic interface, organisation and inclusion of an easy to use assistant make this a standout option

It wouldn’t feel right to not include this option in the list as the local app is fully featured, with excellent organisation, a searchable assistant available at all times, Gist Integration and an excellent interface. The only problem is that it’s not available as a web app, with limited syncing options and the real kicker… it’s mac OS only.

Pros:

Fantastic interface
Great organisation
Searchable assistant for easy to access snippets

Cons:

Local only with limited sync options
Only available on mac OS

If this option was available as a web app it would have been the obvious choice for my top pick, and if you only need access to snippets on one machine and the machine happens to be running mac OS then it should be yours, but if not it’s not a viable option.

Conclusion

There is an option available for everyone here and I urge you to use one of them, set up a collection and share it with your developer friends. The instant access to a whole library of snippets will revolutionise the way in which you write code.