Skip to main content

Why I Code

I love to learn. I am always seeking new knowledge. One of the great things I have learned is that coding is a journey. There is always more to learn. I have spent the last 20 years of my life on this amazing journey and will continue on it.

When we start to learn how to code we learn some great problem solving skills. Coding is not just about typing on the keyboard. It is about taking a problem and breaking it into pieces. We take each of these pieces and turn them into solutions to the big problem. In the end we have made an amazing discovery within ourselves. We have learned how to solve the problems of our world.


Popular posts from this blog

Salesforce - Lightning Components in Communities

Recently I built a Lightning component, tested it as in internal user, and it was beautiful. Everything worked as expected. The work was turned over to the project manager to demo to the client. During the demo nothing worked, just errors. After the demo I received the call. “What did you build? Why didn’t it work?”     I couldn’t understand what had happened. I asked him to show me how he had demonstrated it. He went straight to the community builder, plopped my component on the page, and ERROR! Unbeknownst to me the recordId does not pass to lightning components in the community the way it does as an internal user.
Now you get to learn what I learned.
The problem: Force:hasRecordId does not work in community builder.
The Record ID is not passed by default in the community builder. However, there is a workaround to use it.
The Solution: In your component add force:hasRecordId. This is not needed for community builder; however, it ensures it still works in the internal org as a com…

I don’t test my code and you shouldn’t either.

Wait, what? I am sure about now you are saying something like “Not testing your code is asking for trouble.” Let me clarify, I do not test my code through the UI.
It started about a year and a half ago. I was given a task to write a trigger for a client. The only problem was they had hit the data limit in their Salesforce sandbox. While my project manager worked on getting permission to delete records, I had work to get done. How was I going to do it if I couldn’t create records? Then it hit me, I could use test classes to test my code. This one simple thing changed my programming style. I wrote the code, and wrote very robust test classes at the same time. They had to cover everything I could think of. I couldn’t create a record in the Salesforce UI. When it was done, I had very well written code, and my tests were also complete. Fast-forward a week. We had deleted records and freed up space. The client was testing the trigger we had made for them. They came back with “It’s not work…

Eating an elephant, Breaking Code into tiny bites.

Most people have heard the joke “How do you eat an elephant? One bite at a time.” When programming we often end up biting off huge pieces and trying to shovel them down. We start by building. We are almost always figuring out how to make it work. There is no book that says “If you need to create a sales report here is the code…” The reason is simple, every situation is different. One company might only care about the number of sales in a month. Others might want to track where the sales came from, what interactions led to the sale, the dollar amount, etc. (This later scenario is more likely) We end up with code that is cluttered, is not very optimized, and just plain ugly. What are we going to do to fix it? This is where breaking it into small pieces comes in. In my programming, it is rare for me to have a method that has more than 10 lines of code. Yes, you read that right no more than 10 lines of code PER method. I have had programmers tell me that is impossible. It’s not only poss…