I started my coding days by doing HTML in notepad. I had a WYSIWYG, but the reality is it wasn't coding. I didn't understand what it was really doing. Once I started being able to code HTML myself, I had so much of a better understanding of why a WYSIWYG was built the way it did, and what kind of features I should expect. So I was writing the mark up, but the WYSIWYG editor was a tool. Great for some things, but not the best for others.
Tools make our lives easier and make our workflow better. What we can automate, we should. How we automate different tasks can vary by need, environment, output, etc. But one thing is clear - as we add more tools to our toolbelt, we become more powerful.
- The Power of Plain Text - Plain text is amazing. I understand it, and so do you. I've always said that the best code is the code that a junior developer can go in, and make sense of. This goes for data as well. If something is easy to understand, it is going to be easier to troubleshoot and use in the future.
- Shell Games - Recently, I started using PowerShell and the Azure CLI for some Infrastructure as code maintenance tasks. It makes things so much easier to automate. I don't have to log into the portal, click around and risk breaking something. Instead, I can just call my script with a few parameters and I'm all set.
As I work with more systems, PowerShell will become incredibly beneficial to me. While there is a learning curve, once you get it, you've got it. - Power Editing - Becoming Fluent in your editor is so important. I program mostly in C# and use ReSharper. There are so many keyboard commands and shortcuts that I've already forgotten more than the average developer has ever learned. I keep the keymap up at my workstation and try to highlight specific ones that I am trying to learn. And because I use the IntelliJ mappings, when I work in IntelliJ for a Java project, I already know a lot of those mappings.
The key thing is, I'm more efficient with this in my coding environment, so it saves time and money. - Version Control - Everything is under version control. This is something I'm trying to do. I set up private repositories on GitHub for some of my projects. No one needs to see them, but I can always refer to them. I intend to make more reusable libraries that I can take advantage of things I've coded in the past. Perhaps I turn these into packages.
Point is, by keeping everything, and showing how you got to its current state is incredibly valuable. It shows your progress with the application and as a developer. The part I struggle with is things like contacts, memos and communications - That may be overkill. There's probably better tools for such a thing. - Debugging - Debugging could have a chapter by itself. It has a good amount of content, but there's so much there to help developers solve problems. They should be used. They need to be practiced. Learn how to use breakpoints, conditional break points, logging. I personally want to learn how to read more memory dumps.
Perhaps the biggest piece that was mentioned in this section was "Don't assume it- Prove It". I agree with this but I have a few different ways of saying this. I prefer the saying of, "It isn't that I think you're lying, it is just that I don't believe you." Users don't give great details in their reports and many times they're inaccurate. It is always best to not trust the user (in more ways than one). - Text Manipulation - I don't know any text manipulation languages. I see how they can be valuable for sure though. I worked on a project that was basically managing different XML files, and there were constantly times where I had written an entire C# application to manipulate XML files into some other type of data. Again, anything that can be automated should.
- Engineering Daybooks - Daybooks are awesome and help me so much. They remind me how we got from A to D, who was in meetings, and different architecture ideas from discussions. I've found that it helps to take the notes from a meeting, and then share them with the team via email to make sure everyone is on the same page and that your notes are accurate.
Taking notes is a skill though. Putting a word down in the corner to look into means nothing if you can't comprehend it. I think this is also something that we could go into more detail down the road.
No comments:
Post a Comment