Tag: Professional Development

Book Review: Being Geek

A very interesting blog post turned book written by Michael Lopp more commonly known by his online persona Rands. Rands writes a fairly popular blog called Rands In Repose. His blog covers advice and stories about life, work, and life in technical work.

The content of this book is a series of stories that are easy to read and digest. The content is concise, with a lesson to be had in each chapter. The book covers scenarios across the entire timeline of someone in the technical field. Rands covers things such as finding a job and the interview process managing large teams and architecting projects

Due to the book being a compilation of blog posts it’s very easy to pick up and read a chapter or two, or even skip over ones that don’t fully apply to you. Overall I think this book is super easy to read and has quite a lot of excellent stories with lessons. These lessons can be taken into our professional day to day, to hopefully improve our lives.

Book Review: The Pragmatic Programmer

The Pragmatic Programmer gives true insight into what it means to be a Software Developer with the passion of an artisan. One who strives for improvement in the craft to make things better and more efficient not just for the pursuit of money, but for the sake of doing good work. This book provides an overview of all the different concepts, tools, and approaches to a software solution. I had a friend who said he imagined what I do to be out of the movie Swordfish. In reality, I’m no Hugh Jackman and we don’t spend our time typing at the speed of sound in an abandoned warehouse. Writing code is likely only a small portion of our job. We spend much more time, reading, conceptualizing, and breaking large problems into smaller more achievable ones.

What My friends think I do.

There are a lot of useful concepts in this book, instead of diving into detail I will give you a list, and a strong suggestion to read this book!

  • Always Be Learning and Improving
  • Avoid Over Engineering and Premature Optimization
  • Don’t Repeat Yourself (DRY)
  • Design Code that can be easily changed, Decoupled, Single Responsibility, and Readable
  • Mindset is as important as knowledge.
  • Own your mistakes, Don’t make excuses make solutions.
  • Unit tests are important, but Avoid Over-Testing
  • Version Control Everything!
  • Developers are people, not just a tool/resources.
  • Slice problems down to smaller more achievable chunks
  • Refactor when needed, No broken windows!
  • Think before speaking / hitting enter.

This book provides a great overview and insight on everyday software developer life, while not being overly long-winded. The topics covered in this book can be so valuable not only to new developers who need to learn about these cornerstone subjects but to existing developers to be reminded of the goal in which we strive towards. The book reads like a conversation of a wise developer bestowing all the wisdom tidbits he has gained over the years and finds worthy to pass on to the next generation.

I would say this book is easily a must-read for any developer at least once in your life, the topics are broad, easy to read, and invaluable for your journey towards mastery. Happy Coding Everyone!

Book Review: Patterns of Enterprise Application Architecture

This book by Martin Fowler and assorted others, was published in 2002, but still has content that is still applicable today. It’s a very slow and heavy read, however it is super interesting to see what influenced many of the frameworks that we use today.

This book goes over a collection of Enterprise application patterns that have been vetted in production environments. They are broken into different classifications: Layering, Concurrency, Session Management and Base Patterns. He then goes on to explain the pattern with diagrams, hierarchy and schema examples. Then ends each section with code examples and the pros and cons of each.

If you want more detailed information about the different patterns of enterprise application architecture, feel free to take a look at Martin Fowler’s website. https://www.martinfowler.com/eaaCatalog/

I think this book is a great tome of wisdom, however it needs an upgrade to match up to current design patterns. It was really valuable to see the patterns used at the time when some of our favorite frameworks were built, ie Rails, and .Net. This book is a great foundation for Architects and Engineers who are designing a service or want to learn more about patterns, however not all modern patterns are included at this point.

Build Silly Apps for your Friends

A friend of mine runs a Horror podcast called Nite Shift Video, Horror Movie Reviews, Scary Stories, and Interviews with other people in the Spooky Community. One of the interview ice breakers he does is a scary version of MASH. No, not the old tv show about soldiers in the Korean war. The future telling paper and pen game from grade school.

Mash was a game where you picked some categories and filled them in with choices then people would pick a magic number through various means. Then you would count through and cross off every Nth choice until you were left with one choice in each category. Then that was supposed to be your future.

The host, Nite Shift Jay, would run a custom one they made in pen and paper and have the guest guess a number to decide their horror movie future. However, to cut down on the dead air time as he followed the algorithm of moving through the choices crossing out numbers, Jay asked me to make a website version, so he could just take the number and get the result to keep things running smooth.

With this request in mind, The Mash Website was built. This was a simple project, took me maybe a day to build and deploy once I sat down and did it. However, I did get to learn things even during a small project like this.

  • Utilize Docker to deploy on digital ocean
  • Use LetsEncrypt to secure a subdomain of my root domain.
  • Build a Dynamic Form builder, to allow users to decide how many categories and choices they want.
  • Automate log rotation, docker health checks and automated restarts.

All these things are simple in the grand scheme of things but very valuable to have done yourself. Most jobs you get hired at likely already have a lot of this done, or have someone who manages the DevOp side of things. So it feels good to take something and put it out for the world to use. Obviously, it could use a lot more cleanup and design, however, it served the purpose for Jay. Through the magic of google analytics as well, it seems as at least 24 other people have used it as well. While it’s not changing the world or making me millions, I hope it made someone smile.

Mash Website: https://mash.p3rishable.com/games

Nite Shift Video: https://www.instagram.com/niteshiftvideo/

10% Rule & My Reading List for 2022

I’m going to try to read 34 books this year. I know it seems like quite a bit, and honestly, it is. However, I read a really interesting article about the 10% rule recently. Basically, it’s an easy way to break books up into daily percentage chunks so you can have small and attainable goals to accomplish each day.

The rules are easy:

  1. Create a backlog of books – for this, I selected from several different lists of suggested reads for Rails developers, Management, Startup, and Philosophy books. I took these suggestions and randomized them into an ordered list and decided that is my reading order for the year.
  2. Start Reading – Load them onto your Kindle or borrow them from your local library, and start reading 10% each day. Utilizing the downtime or wasted time, that exists during my day. Whether it’s while I’m waiting for my coffee to brew, or sitting in the dark waiting for my son to fall asleep because his newfound separation anxiety requires I stay in the room until he drifts off.

If you want to join me I’ve included my list below along with Amazon links, or you can use your public library, most have their own app to borrow digital copies of books for free.

  1. Drive: The Surprising Truth About What Motivates Us
  2. Patterns of Enterprise Application Architecture
  3. The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition)
  4. Being Geek: The Software Developer’s Career Handbook
  5. A Guide to the Good Life: The Ancient Art of Stoic Joy
  6. Shape Up – Ryan Singer
  7. Effective Programming – Jeff Atwood
  8. Getting Real – Basecamp
  9. Rework
  10. Design Patterns: Elements of Reusable Object-Oriented Software
  11. Ruby Cookbook: Recipes for Object-Oriented Scripting
  12. Ruby Best Practices: Increase Your Productivity – Write Better Code
  13. Zero to One: Notes on Startups, or How to Build the Future
  14. The Happiness Project, Tenth Anniversary Edition: Or, Why I Spent a Year Trying to Sing in the Morning, Clean My Closets, Fight Right, Read Aristotle, and Generally Have More Fun
  15. The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition)
  16. The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers
  17. Thank You for Being Late: An Optimist’s Guide to Thriving in the Age of Accelerations (Version 2.0, With a New Afterword)
  18. Remote: Office Not Required
  19. Flow: The Psychology of Optimal Experience (Harper Perennial Modern Classics)
  20. Clean Code: A Handbook of Agile Software Craftsmanship
  21. Rails AntiPatterns: Best Practice Ruby on Rails Refactoring (Addison-Wesley Professional Ruby) (Addison-Wesley Professional Ruby Series)
  22. Domain-Driven Design: Tackling Complexity in the Heart of Software
  23. Maverick Startup: 11 X-Factors to Bootstrap From Zero to Six Figures and Beyond
  24. Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
  25. Turn the Ship Around!: A True Story of Turning Followers into Leaders
  26. How to stop sucking and be awesome instead – Jeff Atwood
  27. The Well-Grounded Rubyist
  28. Psycho-Cybernetics: Updated and Expanded
  29. Peopleware: Productive Projects and Teams
  30. Practical Object-Oriented Design: An Agile Primer Using Ruby
  31. Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler))
  32. It Doesn’t Have to Be Crazy at Work
  33. Eloquent Ruby (Addison-Wesley Professional Ruby Series)
  34. Meditations: A New Translation

I would love to hear what books you plan on reading this year, and if you have any book suggestions to be added to my list for 2023. Feel free to let me know in the comments or on my socials. I will try to give some quick reviews on the books after I finish them, as well as update my progress throughout the year. Until then Happy Reading!

Asking for Help is Not a Weakness

“Never let your ego get in the way of asking for help when in desperate need. We have all been helped at a point in our lives.” – Edmond Mbiaka

Developers often don’t ask for help soon enough. They sit and spin their tires determined to try to prove they can solve the problem themselves without any help. This can lead to shoddy code, wasted time, and frustration. This feeling can likely be traced back to the imposter syndrome that most developers feel no matter which stage of their career. That itching feeling that everyone knows that you have no clue what you are doing, that you don’t belong here, and if they find out that you can’t solve everything, fast and perfectly you might get fired. The truth is, everyone struggles and the most successful developers know where to find that line between a valiant attempt to solve a problem, and stubborn time-wasting out of fear and pride. 

Asking for help is not only good for you and solving the problem that is impacting the progress. It is also a valuable experience for the person whom you ask. The process of explaining the problem and finding a solution forces both of you to think deeply about how the system works to communicate it clearly.  

While we teach, we learn. – Seneca

The Roman philosopher Seneca said, “While we teach we learn”. This is what is known as the Protege effect. A study was conducted that found that students who tutored were more inclined to learn and retain knowledge at a higher rate than those who did not.  Obviously, we can’t ask for everyone to go out and find an apprentice like in olden times to teach the craft to. However, We find ways to teach through other means: Pair Programming, Blogging, making videos, journaling and tutoring. 

However, when you do ask for help it is important to keep a few things in mind. Asking for help can’t just be about you relying solely on the other person to fix your problem. It is still your responsibility to contribute, ask questions along the way. Ask for explanations of how the system works, why your attempts didn’t work, and how you could have approached the problem better in the future. There is nothing worse than someone saying they need help than sitting in silence or on their phone next to you while you complete their task. It is very reminiscent of school group projects when the one person doesn’t help and just adds their name to the title slide. Don’t be that guy. 

So don’t be afraid to reach out for help. Most of the time people will happily help you because it validates them in their own position in the field. Knowing someone comes to you for an answer makes you feel solidified and helps push down those feelings of imposter syndrome. 

Effectively Deal with Recruiters

So as a software developer I get a lot of different communications from recruiters. Linkedin, emailing, and cold calling are the worst culprits. Now sometimes there can be a good opportunity amongst the slew of people just buckshotting jobs that require skills  that are not even applicable to your own skill set. I hope to share some good practices to optimize your time, and success in finding a good opportunity amongst the sea of spam. 

Pre-Screening: 

This means on that initial reach out. Whether it’s a “wow you’re a great fit for our company” Linkedin blast or a cold call. You as a person have just as much a right to pre-screen companies as they have to do the same for potential hires.

1. Always ask for a job description 

This will cut a lot of wasted time. There are so many times where I have gotten a message saying you’d be a great fit, we have cool culture and cookies come join us. Then when you reach out and ask for what kind of technology you would be working with. They say Java, or Cobalt or some other technology that is nowhere on your Linkedin, resume, or even your reading list. Getting a job description will immediately get you a vibe of what the company is looking for, if your skills are applicable and if it’s a tech stack that you are interested in working in. 

2. Ask for a pay band. 

Most places won’t tell you any actual numbers, and typically you don’t want to reveal yours either for negotiating reasons. However a pay band is perfectly acceptable. This will also help weed out offers. I live in the second cheapest city in the United States. So when I get contacted by a local company I can pretty much rule them out, because if you work remotely for companies in California or New York the normalized pay scale is so drastically different. So finding out a pay band is basically a polite way of finding out if it’s worth your time to keep the conversation going. 

During the call :

A basic checklist of things that you should always have covered with your first call with the recruiter to get you set up for success moving forward or bailing out. 

  1. What will I be working on, What is the company or product about, what would my part be in it. 
  2. What technology will I be using, LAMP, MEAN, Rails. This can give you a better idea what to freshen up on before the first interview. 
  3. What is this company’s interview process like? With how drastic some interview processes have gotten now in the developer community from Take home Projects to Live coding in front of a panel. Knowing how many and what the rounds will be is a good way to judge if you want to expend the energy on this company.
  4. Benefits and Extras  – Health coverage, Snack Budget, Company Tesla, Jetpack allowance. All things that are important when judging multiple offers or the value of your current workplace. 
  5. TimeFrame to hire. This will give you an idea of how fast they want to move and can give you a plan on how to plan your exit in a successful interview process. 

I hope you find this checklist and tips helpful. If you have any tips to share or if you try it out let me know how it goes in the comments down below!