I have never written a blog post of any kind. This is just as much a new experience for me as starting in development is for you. However, the goals of this post are to reach out anyone who may be new to writing code and give you a little perspective.
About Me
Just a quick blurb about myself: I am a Senior Software Engineer at a payment processing company. We specialize in making payment acceptance accessible for businesses of all sizes with both Mobile and Traditional solutions. My sole responsibilities include both API Development and Business Intelligence Solutions. Our core stack is a combination of nodejs, PHP, and Amazon Web Services.
I have been writing code for 10 years. I spent One Year on the Product Support team before moving into my Junior Developer role. I spent three years in that role before being promoted to a Senior Position. None of this was because I was the greatest gift in development since Bill Gates or Mark Zuckerberg.
Misconceptions
A lot of Junior Developers have this idea that if they want to be 'worthy' of a job in programming, they need to be able to code at 600 words per minute, be a touch typing master and be able to write an entire application - from start to finish - perfectly the first time and without issues. This is simply untrue.
You might have someone you admire and you watch their pre-recorded courses or YouTube Videos to learn about different technologies. It might seem like every amazing developer is capable of just typing out their thoughts as they go without any need to plan for construction. That is the power of editing. The best videos to watch are live coding sessions. These give a better insight into the thought process, planning and refactoring that is done. Albeit, these things aren't as sexy as just coding away - it's the reality of development.
Reading Docs
I talk with many developers - both online and offline - and the general consensus is ... nobody really goes long without reading documentation. There's no good way to fully commit an entire development language to memory; especially when technology and languages are fast evolving. Adding new features, deprecating features, etc. DO NOT be ashamed of having to refer back to the docs for things. There's a reason Google is the number one search engine amongst Software Developers ;)
Don't Be Afraid
There is always going to be imposter syndrome when it comes to whatever it is you're doing. "Am I good enough?", "ZOMG they're going to find out I have no idea what I'm doing!!"
I'm not here to break down the psychoanalysis of this thought process is - but you aren't alone. You have crossed the biggest barrier than there was to get into development ... WANTING to be a developer. That's pretty much it. You don't need to have some kind of burning desire to never stop coding; you don't need to dedicate nights and weekends on side projects; you don't have to take advice from these know-it-all Seniors (wink wink). You just need to want to do what it is you're doing. Go at your own pace, decide for yourself what it is you feel comfortable with and just be comfortable. You ARE good enough ... otherwise, you wouldn't have the desire to even be in coding in the first place.
Dev Process
This one is probably going to be the most difficult to explain because, let's face it, everyone is different. For myself (and I have discovered an entire community of people like this) - I will just try to get code in place that does the thing I want to do. I don't care about the coding principles; I am not paying attention to whether or not I have duplicate logic or whether I am constructing objects in the most architecture appropriate way. I just put something in and test to see that something works.
I have folders on my local machine dedicated to 'tinkering'. New concept added to the language? Tinker... Want to see if this string of methods works? Tinker ...
A lot of us will get the concept in place and see that we have success before paying more attention to the abstraction of the code and following design principles. Don't be ashamed to follow your own process. It's only code and it can always be refactored along the way.
End
I apologize for the long windedness of this post. I do accept criticism (I welcome it being that this is the first time I've done this ... ). Most importantly - I hope at least one person reads this and has more confidence going forward. If you have any questions or just want to tell me how wrong I am - please leave a comment below :).
Oldest comments (3)
Good article, I don't find it verbose, but then again I'm senior myself!
I think the most challenging factor is to assert if you're fit for the role, which also applies to the person coaching or mentoring, a spot where I find myself often.
Surely everyone can learn to write code, play a musical instrument, write a book, pretty much any human activity can be experimented by any human, to do that on a professional environment is whole new ball game.
Bottom line is, not everyone with computer science / information technology academic background or proficiency is fit for every role in the computer science / information technology landscape.
There are many people that want to be developers, can code to a certain extent and are even fairly good with algorithms and all that jazz, but maybe lack the ability to focus on finishing tasks or are especially difficult working in teams.
Likewise there are many people that want to do more conceptual work such as architecture, and might even have the technical experience, but maybe lack the ability to generalize problems and be truly agnostic and unbiased (which is hard).
I agree with pretty much of what you wrote, but would like to add the vital importance that coaching and mentoring have in guiding people to find their true calling, where they will be the happiest, performing at their best and adding the most value.
Having said that, it should never be a too constraining guidance and it's very important to understand that everyone once knew very little about what they were doing, and exploration should be encouraged.
The last thing we want is people that are not motivated with what they are doing, the second last is people that think they are really good at what they are doing, but are not, so information and communication is key to get to that middle ground.
Maybe went a bit off-topic here ;)
Good stuff!
Or, as Donald Knuth so famously put it...
You can't optimize something that isn't working yet. There are a lot of perspectives on this, but in my experience, "build first, refactor next" is by and away the most reliable approach. You may eventually form some habits and instincts regarding good and bad practice that affects your first attempt, but these are merely personal habits and conventions. You'll always need to refactor later for it to be truly good code.
Side Note: As an author, never apologize for "verbosity". Use as many words as you need to express your idea. William Strunk Jr. was right when he said "omit unnecessary words", but that's something you (or an editor) catch in revision. **Don't apologize to the reader for it.* If it matters, edit; if editing isn't a prioritization, just let it slide.
And, by the way, this article far from long-winded. If you want to see "verbose", I have a few rather long articles on this platform, although I'm not "sorry" for them. They're as long as it needed to be.
TL;DRis the apathy-rooted enemy of learning.Cool. Thanks for posting. Its really hard to find a reality based experience nowadays, It just looks like everyone is a 10x developer.