Pragmatic Programmer : Chapter 1 - A Pragmatic Philosophy

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.