After reading a recommended book by a friend, I wanted to talk about the Nike's old marketing slogan, "Just Do It.", and it's relationship to my programming experiences. Nike's "Just Do It" slogan really helps me answer those 50/50 questions or "hmm, we could probably use this snippet of code in other places, but I am not sure if it should be reused" or "this might be a pretty good idea, but I am not sure if we have permission to do it." you have when you are programming. Do what you think is right. Basically, JUST DO IT! There have been so many times another programmer or myself have been stuck or afraid of making a business decision becomes of fears of the wrong outcome. The fact is "no one likes to make decisions" period, so presenting it to another person really just causes frustration. So just code it the way you think it needs to be done.
Now, I am not saying you should do this for ever decision but most of the decisions left up to a developer are minor in the eyes of the user. They want you to tell them how they should work and they will tell you what's missing, named wrong, or doesn't work. So I invite you to be bold like Nike and "Just Do It.".
Throw that extra icon or link in there.
Set the smart default you think you would use the most.
Constrain the user to a set of options to choose from to better focus the experience.
Once it's coded and demo-able, have another couple set of eyes look at it. They will tell you what works and doesn't work, but at least you create some discussion on your concern by showing. Showing is such a strong yet hard thing to accomplish in programming, because it's hard to finish something. By getting something to show you are very close if not finished with your task. People aren't dump, they will notice the changes you did and if they don't that means they don't care and your in the clear or you chose "what the user will naturally want" and it will work. Either way it's a silent win for you.
If you spend too much time deciding how something should be done vs. doing it, more and more requests will be added and you will get overwhelmed with tasks. Just code it and demo it to a group of people, whom will spend the next week ripping and tweaking the piece you created, until they figure out what they want. Where this kinda sucks cause you will have to go back and look at your code, you will find out what worked and didn't, be able to create some direction for your self by involving others in your concerns, and be more prepared for the next task for which you can transfer the tips you learned. It also allows you to focus more on code instead of managing politics.
In recap...Just Do It!
Monday, March 15, 2010
Simplicity vs. DRY code
I was in a pickle today over whether or not to consolidate code or keep it a little bit wet for simplicity sake. I consider simplicity sake, going to a view and not having to unlock the rubric's cube of "if" logic. If you are not familiar with wet and dry code, wet is where you repeat yourself over and over and dry is where you "Don't Repeat Yourself (DRY)". I went with "Simplicity". I decided to consolidate parts of the view, yet repeat myself a little. I found this to be safe because I felt like the views would grow and I didn't want it to end up with a crazy page that only the maker has the key to unlocking its craziness. Yeah, we have all seen some of those old pages that are a disaster to debug and I didn't want to start that trend. Also, I wanted the next person behind me to get in and out of the view as quickly as possible. It wasn't very much fun going through every view and updating the same piece of code...but it was simple.
Sunday, March 14, 2010
Small == Big
Have you ever tried to over architect something so that it fits all cases and solves world hunger?
I think we have all ran into this problem before and I think it's due to fear. We are afraid that the wierd, the one-off case comes along and we have to re-work our code that we spent so much time and thought into. Let's be honest no-one likes to go back and repeat something all over again, just because of one little feature/request. Sadly, no matter what you do, it will quickly become out-dated and need to be looked at again. On the flip side, the cool part is that you get solve the issue in a new way.
One thing that helps remind me not to over architect something is to start small. Solve your issue for one record. Example: "Add one user to the system". Solving for one record helps you identify the core pieces that make up the record.
Next, go back and tweak your code to do a group of records. Example: "Add a group of users to the system." Processing records in a group helps save the end user time.
And finally package your code, if you it's generic enough, to be used by other systems. Packaging helps the next developer who needs to solve a similar issue jump start there development efforts and gives them a feeling of "safety net" that someone else can help them if they get stuck.
Going back and touching your code sucks but it can be made more fun if you try to solve for the group of records and packaging. It will help you discover a new solution to your issue and keep you interested in your re-work.
Remeber:
1. One record
2. A group of records
3. Package it for the next developer
I think we have all ran into this problem before and I think it's due to fear. We are afraid that the wierd, the one-off case comes along and we have to re-work our code that we spent so much time and thought into. Let's be honest no-one likes to go back and repeat something all over again, just because of one little feature/request. Sadly, no matter what you do, it will quickly become out-dated and need to be looked at again. On the flip side, the cool part is that you get solve the issue in a new way.
One thing that helps remind me not to over architect something is to start small. Solve your issue for one record. Example: "Add one user to the system". Solving for one record helps you identify the core pieces that make up the record.
Next, go back and tweak your code to do a group of records. Example: "Add a group of users to the system." Processing records in a group helps save the end user time.
And finally package your code, if you it's generic enough, to be used by other systems. Packaging helps the next developer who needs to solve a similar issue jump start there development efforts and gives them a feeling of "safety net" that someone else can help them if they get stuck.
Going back and touching your code sucks but it can be made more fun if you try to solve for the group of records and packaging. It will help you discover a new solution to your issue and keep you interested in your re-work.
Remeber:
1. One record
2. A group of records
3. Package it for the next developer
Indexed views, not using your indexes
I was working on an export where we were building a query in a string to be passed to a CLR through a stored proc to a small .NET assembly on the db server and ran into some issues with performance. Now, of course CF is slow at running queries...that's why we passed to it .NET to handle the execution, but I didn't think .NET would be slow. I couldn't figure out why my query was slow for the life of me. All the indexes were place, no extra joins were added and the query still took 20 minutes to run. After talking to a DB developer he told me that even though we indexed the sql "views" the indexes were not being used. I quickly freaked out wondering why SQL didn't use the indexes on the views like it uses the indexes on the tables. It should be assumed. Turns out the reason was that, "It is just one of those things". To fix the issue we added "with noexpand" to the joins to the indexed view and then query time went down to about 8 seconds. Ridiculous.
StructSort() does not sort your keys
Ran into an issue on Friday where I was trying to sort a struct numerically by it's keys. My struct looked something like this {"1"= query,"11"=query,"2"=query}. I first tried StructSort(struct) but it didn't work for me, it kept erroring on me. I wanted my keys to be sorted like this 1,2,11 but we all know CF automatically sorts your structs alphabetically.
So I tested structSort() with a different struct like this {"1"= "1","11"="11","2"="2"}. Bam! It worked. Hmm...something is fishy here. StructSort() works with simply values, but not complex values...but it should be just looking at the struct's keys. Anyways got around it by doing this listSort(structKeyList(struct))
So I tested structSort() with a different struct like this {"1"= "1","11"="11","2"="2"}. Bam! It worked. Hmm...something is fishy here. StructSort() works with simply values, but not complex values...but it should be just looking at the struct's keys. Anyways got around it by doing this listSort(structKeyList(struct))
Tell the join how to join.
I have been having a lot issues…with query execution plans lately (using CF and SQL). SQL has been choosing shitty plans thus making my query slow. If you have ever looked at execution plans, they are difficult read...unless you are a DB developer. I have had no idea wtf was going on with these plans…until now. Another developer sent this great link explaining what the joins are doing in the execution plan. You can then tell your joins in your query how to join.
Example:
select * from [user]
inner hash join enterprise_user on enterprise_user.user_id = [user].id
An execution plan does more than just join identification, such as indexes, but the join thingy is all I really cared about at the moment.
P.S. Only specify the “how to join” if you have to; if your query blows at running, let SQL try to calculate the best plan.
Use Case: Had a query in cfquery tags and it was choosing an execution plan with nested loop joins instead of the fast hash joins.
Example:
select * from [user]
inner hash join enterprise_user on enterprise_user.user_id = [user].id
An execution plan does more than just join identification, such as indexes, but the join thingy is all I really cared about at the moment.
P.S. Only specify the “how to join” if you have to; if your query blows at running, let SQL try to calculate the best plan.
Use Case: Had a query in cfquery tags and it was choosing an execution plan with nested loop joins instead of the fast hash joins.
Tuesday, February 16, 2010
Developer's Inspiration
I have read a lot of blogs of web designers who have a post about "Sources of Inspiration" and I just wanted to through one out there for the developers.
The outdoors is a great way to relief stress and concentrate on a single problem. In other words, "It gives you a chance to clear away all the daily bull shit and focus on the problem at hand." When I am talking about "The Outdoors" I am not talking about having your window open while you play video games. I am referring to remote areas usually where vehicles can't go. Examples of outdoor places would be the woods, a cliff, or a lake/river. I personally find the woods to be the most beneficial because of the silence and random things that can keep your eyes busy and your mind relaxed, yet turning.
We as developers don't care that much about the looks of that app or naming things in it...even though we should. I have had many walks in the woods where I have came up with a solution for a navigation issue by just looking at how the trees where aligned, just as an example of how the outdoors have inspired me.
A few things that can create inspiration:
• Hiking/walking in the woods
• Mountain biking
• Hunting/Archery
• Golfing for pleasure.
• Lawn mowing...because you get in the zone, at least I do, and nothing else matters. Until you mow over the flowers.
One word...Lego’s. Lego’s, in case you don't know, are small little bricks that fit together and you can build things out of them. Kind of like pieces of code that form an app in nerd speak. While the outdoors in the section above focus more on freedom, constructing things focuses on constraints. When you construct something you are usually limited by the resources you have available. Example you are building a bed and you only have steel, well how do you make the most out your steel to maximize the outcome of the bed. The constraints force you to be creative to solve a solution and often require you think in a different way. My uncle told me a quote once that helps describe this better than I am right now. He said, "Poverty is the fuel of innovation". Poverty is the problem and the constraint and it requires you to maximize the outcome. We as developers can relate to this easily by having very little time or resources as our constraint and a business requirement as our problem.
A few of things that can create inspiration:
• Lego’s
• Carpentry
• Chingling a roof
• Arts and crafts...if you are in to that stuff.
Kids are great for inspiration because they see things in a simple way and don't care about the complexities. Often times we only see things in a overly complex way because we are trying to account for all the bullshit one-off requirements that we are trying to satisfy. Sometimes if we break these complexities into simple pieces it helps you see the hidden path through the labyrinth of craziness. A thing that web designers do that I am going to steal because developers don't do it enough is "The drawing board." This is the concept of writing all your complexities on a white board and moving them around and fine tuning them until you can see the path. Granted sometimes you need a really big white board but it does help to break things down.
Another thing that kids do well is trying hard at something they suck at. An example of this would include watching 4th graders play basketball. The hoop is clearly too high but they don't care because they are focused at getting a basket. I was able to figure out how I could refactor an old spaghetti code app by watching some kids play basketball. Watching them help me separate the old code into modules with which I could slowing fix while keeping the old code working. How does this apply to the kids playing basketball you might ask?
The kids all crowded around the bottom of the hoop = the spaghetti code.
Pulling one kid aside and explaining to him that if you stand by the free throw line you will be open for a pass by teammate = separating the spaghetti code into modules.
...nothing really to say here, we all know.
There is a ton of developers and designers blogging inspiration. Read them and take what you need
Outdoors
The outdoors is a great way to relief stress and concentrate on a single problem. In other words, "It gives you a chance to clear away all the daily bull shit and focus on the problem at hand." When I am talking about "The Outdoors" I am not talking about having your window open while you play video games. I am referring to remote areas usually where vehicles can't go. Examples of outdoor places would be the woods, a cliff, or a lake/river. I personally find the woods to be the most beneficial because of the silence and random things that can keep your eyes busy and your mind relaxed, yet turning.
We as developers don't care that much about the looks of that app or naming things in it...even though we should. I have had many walks in the woods where I have came up with a solution for a navigation issue by just looking at how the trees where aligned, just as an example of how the outdoors have inspired me.
A few things that can create inspiration:
• Hiking/walking in the woods
• Mountain biking
• Hunting/Archery
• Golfing for pleasure.
• Lawn mowing...because you get in the zone, at least I do, and nothing else matters. Until you mow over the flowers.
Constructing Things
One word...Lego’s. Lego’s, in case you don't know, are small little bricks that fit together and you can build things out of them. Kind of like pieces of code that form an app in nerd speak. While the outdoors in the section above focus more on freedom, constructing things focuses on constraints. When you construct something you are usually limited by the resources you have available. Example you are building a bed and you only have steel, well how do you make the most out your steel to maximize the outcome of the bed. The constraints force you to be creative to solve a solution and often require you think in a different way. My uncle told me a quote once that helps describe this better than I am right now. He said, "Poverty is the fuel of innovation". Poverty is the problem and the constraint and it requires you to maximize the outcome. We as developers can relate to this easily by having very little time or resources as our constraint and a business requirement as our problem.
A few of things that can create inspiration:
• Lego’s
• Carpentry
• Chingling a roof
• Arts and crafts...if you are in to that stuff.
Kids
Kids are great for inspiration because they see things in a simple way and don't care about the complexities. Often times we only see things in a overly complex way because we are trying to account for all the bullshit one-off requirements that we are trying to satisfy. Sometimes if we break these complexities into simple pieces it helps you see the hidden path through the labyrinth of craziness. A thing that web designers do that I am going to steal because developers don't do it enough is "The drawing board." This is the concept of writing all your complexities on a white board and moving them around and fine tuning them until you can see the path. Granted sometimes you need a really big white board but it does help to break things down.
Another thing that kids do well is trying hard at something they suck at. An example of this would include watching 4th graders play basketball. The hoop is clearly too high but they don't care because they are focused at getting a basket. I was able to figure out how I could refactor an old spaghetti code app by watching some kids play basketball. Watching them help me separate the old code into modules with which I could slowing fix while keeping the old code working. How does this apply to the kids playing basketball you might ask?
The kids all crowded around the bottom of the hoop = the spaghetti code.
Pulling one kid aside and explaining to him that if you stand by the free throw line you will be open for a pass by teammate = separating the spaghetti code into modules.
Video games and movies
...nothing really to say here, we all know.
Other blogs
There is a ton of developers and designers blogging inspiration. Read them and take what you need
Subscribe to:
Posts (Atom)