Matthew Lang

Jonathon Snook has been sharing a few thoughts on imposter syndrome and what he’s doing to overcome it.

It seems that every once in a while I go through this same phase of self-doubt, but it’s never been as bad as it was a couple of months ago. Giving up on freelancing and returning to a full-time job required a series of significant changes that added to this phase.

I was no longer working for myself. I would be working for an employer and therefore also working with and for other people. When you’re freelancing, there’s an element of being a lone wolf. It’s not entirely isolating, but you don’t need to worry so much about other people. You deliver what the client wants. Working for an employer is different. You have to align yourself with the companies goals and those that you are working with.

Working from home for some years means that I was fortunate enough to find my own routine that worked for me. From the comfort of my house, I could play the music I wanted, take breaks when I wanted, plan my day how I wanted. Working for an employer means being in the office at certain times, aligning your work day with others, making yourself available when others require your time.

Adding to these were some routine changes at home and facing the possibility of a frequent commute. The whole experience led me to question whether I could do the job I was applying for. Not only that, but I was examining the worth of some side-projects I was working on as well as a career change that I am considering for the future. It’s was similar to Jonathon’s stage where at the point of execution, you freeze up.

Every time I get to the point of execution on anything, I start to freeze up. I hit a wall every time I want to put myself out there.

— Uneasy by Jonathon Snook

After a few months in full-time work, however, I’m starting to find that I can do the job although given it’s a new role, there are a few weeks of finding your feet.

Not only that, but I’m also reading more, writing more, coding more outside of work. I’m doing these things as they help me build myself back up out of a period of self-doubt. I’m now at the point where I am finding myself enjoying side-projects and returning to a stage where I can see myself executing again.

One of my big downfalls, when I start work on something, is wondering if I am going in the right direction with it technically.

Web development is always changing. It is getting better though. Javascript frameworks are starting to settle down, and fall in line with the regular releases of non-Javascript frameworks like Ruby on Rails and Django.

For the last few weeks, I’ve been reading about Javascript frameworks like Vue and React and what they can offer for web applications. I’ll be honest and say that I’m still not sold on the idea of creating single-page applications with these frameworks, but I can see where they become a benefit for complex web pages.

Then there are things like CSS frameworks, deployment options, containers and a whole ream of other things to consider for the right stack for the application. It’s then that I find myself in a state of “decision limbo”.

Ideally, I would use Rails and a CSS framework and start from there, however, I’m always questioning what should be considered as an alternative.

While reading Nick Janetakis’ article on growing into microservices, I happened across this little nugget of wisdom.

You get better by writing a lot of code with absolute and total intent to replace almost everything you write with better code once you start experiencing real problems first hand.

Microservices Are Something You Grow Into, Not Begin With by Nick Janetakis

I needn’t worry about the implications of my technical decisions until I come across some real technical problems. When I do come across those problems, I should only look at the options available to me then.

In other words, just write damn code Matthew.

On a final note, Nick Janetakis’ article is an excellent guide to those starting new development projects and looking to use microservices. In a nutshell, don’t.

I’m with Kurt on this, amen brother.

In my diet plan you can have as much coffee as you like. Because in my diet, you drink coffee because it tastes so damned good.

— Blah, blah, blah by Kurt Harden

With a new full-time role, I’m in the process of getting my head around some of the technology choices I’ll be working with and the benefits and drawbacks of each option.

One of those choices is building single-page applications (SPA) with a JavaScript framework for the front-end. I can see why this choice was made, but I’m now weighing up whether it is worth considering for my own projects. With that in mind, I’ve been doing a lot of reading about single-page applications.

I liked Jim Newbury’s article on single-page applications and his point about understanding what you are building.

We ask “What framework should we use for this whole app?” for new products up front, when we don’t even understand what we’re building yet. It’s far less wasteful to ask “What technical approach best supports this user need?” on a case-by-case basis as we learn more about those user needs during incremental product design and development.

— Create your own dysfunctional single-page app in five easy steps by Jim Newbury

Sure your team might be well versed in building single-page applications, but it’s not the best fit for all types of applications. It’s all about finding the right tool for the job.

Ruby on Rails is a good starting point for most of the projects that I work on, but I know it’s not a good fit for other types of projects. For other projects I know I would need to use another set of development tools.

I understand the benefits of using single-page applications, but it’s not a style of application that will yield immediate benefits in my own, smaller projects. I’ll stick with the tried and tested multiple-page application monoliths for now.