Wednesday, September 15, 2021

Pragmatic Programmer : Chapter 2 - A Pragmatic Approach

 The Pragmatic Approach talks about the steps for architecting and planning how to do your development. At times these chapters can seem like a hodgepodge of subjects, but when you consider all of these steps before you start developing, they can be some of the most basic and important steps in development. 

Setting the pace and expectations are key for getting the business and development team in line together, so by these simple steps, the teams can function optimally.

  1. The Essence of Good Design - Good design is easier to change than bad design. It sounds so simple, so why don't I think about it more? This is a great way to present to people a way to handle the design of their code and libraries. I should be able to swap out different layers and UIs and not have to worry much about the behavior of unrelated pieces being impacted. 
    In the past, I always used the idea of Automated Unit Tests for keeping abstraction in place, but this is an even better ground rule of handling things that I want to use in the future.
  2. DRY - The Evils of Duplication - Duplication is inevitable when you work on teams. Sometimes people have things out there that you're unaware of, sometimes someone copies and pastes code repeatedly into the codebase - these are things we need to work at preventing.
    The part I found very interesting is that the idea that documentation itself is a form of duplication. It makes sense and I never thought about it that way. It almost feels like if we can auto-generate as much of our documentation as possible, that we could greatly reduce the duplication. 
    This is a new idea to me that I'm going to spend a lot of time thinking about going forward in my development career, and come up with different ways of not having the same information in my documentation and my codebase.
  3. Orthogonality - We're drifting into the idea of the Single Responsibility Principal of Solid Design. I love the analogy of the helicopter levers impacting each other.
    There's a lot of good strategies for handling orthogonality, and it even talks about the singleton pattern which can lend itself to its own challenges. 
    This comes down to small, focused pieces of code. Know what it is doing and have it do just that. If a client can have multiple accounts, those functions need to be separated. If an address can belong to a client and a customer, then they must be separated. If a mailing address can be international or internal, they must be separated. They're going to have different functionalities with different requirements, like postage or customs. Changing postage shouldn't impact internal mail. 
  4. Reversibility - Reversibility and having a flexible architecture is more and more important as technology advances. Containerization is drastically showing that, and abstracting away as much as you can is going to be critical for your codebase. You may have some infrastructure code, data access code, business logic - be prepared for it all to change dramatically.  Make no mistake, this is all about abstraction. 
  5. Tracer Bullets - I use tracer bullets without even thinking about it. Recently with the different variations of .Net Core, and the .Net Framework, its very easy to get confused with libraries and what can reference what. I work with older assemblies and I tie into new pieces that run on linux based machines. Making sure everything can communicate, getting those basic lines of communication in place are critical. 
    Building your project framework, showing the integration, and getting those basic pieces down early are absolutely critical to not having to go back in 6 months and change the foundation.
  6. Prototypes and Post-it Notes - I'm very hesitant to do any sort of prototype in any technical tool. They always seem to end up being used in production or how they were not intended. The business does not care about architecture, just that something is working right now.
    That's why I love the idea of wireframes, post it notes, Power Point presentations and mock ups. They communicate quickly the idea of how something should behave, and they cannot be deployed.
  7. Domain Languages - I don't have a ton of experience with Domain Languages in terms of planning. I've used Given When Then statements, and SQL, but often times, I feel in the planning stages, they can become overwhelming. I'd like to get some more experience with these and understand their benefits a bit more.
  8. Estimating - If naming things is the hardest thing in development, estimating may be number two. Estimating different tasks and  when things will be completed requires so much and often you don't have enough to formulate a proper estimate. You can add in caveats and assumptions, but when those are wrong, and you miss your deadlines, it is my experience that you will pay. The time for estimates, and post-mortems would be better spent ironing out what needs to be done, and actually developing.
    Now that isn't to say all estimation is bad. After all, effort must be distributed appropriately to get the best bang for your buck! I do like the idea of tracking your estimates, and keeping track of how long you spend on different tasks. But again, time consuming.
    I also love the idea of regularly updating the schedule with the code. Being able to accurately project when something is done has value, but things change so fast and frequent, projecting more than a couple of months in advance doesn't seem greatly beneficial to me.

Monday, September 13, 2021

Pragmatic Programmer : Chapter 1 - A Pragmatic Philosphy

Your attitude towards your work makes things very different. Do you have a job or a career? Pragmatic Programmer reminds you that it is a career. Your attitude and behavior shapes your career, setting you up for being a better developer long term.
  1. It's Your Life - I've seen a lot of developers just throw their hands up in the air and not even attempt to make things better. It can be as simple as just getting a nicer mouse for their own desktop. There's a sense of entitlement among many developers, that everything needs to be handed to them in terms of training, or their work environment. That's a shame.

    Take control of your ability to complete your responsibilities, even if that means investing in yourself. The idea of "You Have Agency" is a great way of looking at things and separates craftsmen from workers.
  2. The Cat Ate My Source Code -We all make mistakes. We all find others' mistakes. Ownership of your work, and the mistakes that have been made really changes the attitude and tone of your team. Reaching out for help, alerting others to those mistakes early is key. Perhaps things can be adjusted to still meet the goals. However, when you do make a mistake, do whatever you need to to resolve said mistake. If you need to come up with a list of options to do so, put in extra time, do it. Document it. Be an example of someone you want to work with.
  3. Software Entropy - When I first read this book, I thought this idea was garbage, but the idea really is true. I now recognize this is a bigger picture item.  Bugs need to be documented, and incomplete pieces need to be shown in the code. Finding the right ways of doing that can be difficult though. Fix what you can, when you can.
    When things are broke, you may not be able to fix right away. If you can, go for it. But you need to make others aware of it. It can result in extra testing and requirements gathering. Things didn't get to their current state by accident and there's probably a reason that the problem exists. 
    Just make sure you're going in the right direction.
  4. Stone Soup and Boiled Frogs - Being a catalyst for change can be difficult. Rocking the boat really can upset people who are resistant to change and don't want to do things differently.
    Making those changes is difficult and takes practice. There's always a lot of different factors involved including time, resources, money and long term vision. You may not always be successful, but maybe you can combine ideas with someone else to make things just 1% better.
  5. Good-Enough Software -  The best line of software is one that is not written. I use different libraries all the time, and those bring in bugs. I use other team's NuGet Packages and thus, I can inherit defects from that. It goes on and on. 
    The point is, we have resources available and sometimes the requirements aren't as strict as we come to believe. If the 40 hours it takes to add a feature saves users a total of 10 minutes a year, maybe it isn't worth it. Do the right things from the beginning like Automated Unit Testing, and Continuous Integration where it makes sense.
  6. Your Knowledge Portfolio - Having different tools, different ways of solving problems, knowing about how others solve their problems is huge. I believe that learning things takes a long time, and takes a lot of effort. I'm no longer in college where I can stay up three nights in a row studying and absorb everything I studied. By doing things regularly, and in different ways, you become a well rounded developer with a variety of ways that you can solve problems.
  7. Communicate! - I wish I paid more attention to this earlier in my career. Some of the best training I got in the last 5 years was how to write an email. This chapter reminds me that we're in an age of different generations, and that comes with different communication styles. More experienced technical people may want to talk through something to communicate an idea. I'm a huge fan of a wall of text in an email (that people don't seem to read), while developers fresh out of college seem to lean towards visuals like charts, and videos on things. These are tools, that have their own benefits and flaws. Use all of them, not just one. Pick the right one not just for the context, but your audience.
    Additionally, the idea of code comments being documentation violating the DRY principal is something I had not considered. I've gone all over with my comments in code from being too verbose to non existent. This is something I think deserves to be explored in a deeper sense. 

Pragmatic Programmer : Your Journey to Mastery

I recently was in a meeting where I was reminded of the idea that exceptions should be used for exceptional cases. I thought it was in Pragmatic Programmer, but I've purchased and loaned this book out so many times that I could not find my copy. I talked to another developer about these exceptions, and mentioned the book. They genuinely seemed interested, and I wanted to revisit the book since I was overdue. So I bought the hard cover 20th anniversary edition, and it will not be loaned out. I rather buy one for someone than lose my copy again.

This has been the most beneficial book to my career. I've read it multiple times, and feel called out by it regularly. It refreshes me on keeping focus on my career, and being a better developer. Very quickly, you learn that it isn't just who knows the code the best being a valuable team member, but who can maintain the code, communicate, work together, solve problems and come up with long term strategies. There's minimal code in it, and they're more about strategies to solving the different challenges that come with development.

This is an excellent book, that I recommend for anyone with over a year of development experience. I've decided to make my own cheat notes to come back to from time to time as I read this book. I'm also happy to discuss any of these concepts and ideas. My notes can be found with the Pragmatic Programmer tag.