No posts in a while. I think this particular blog is about to become an archive. It has some pretty good thoughts, and a few IT tips, so I'll leave it up for a while. But since I'm no longer writing code on a daily basis, the inspirations have been few and far between. But I love to write - so check out my creative stuff at:
The Sea, The Sun, The Fields, The Tide
Tuesday, August 31, 2010
Wednesday, July 28, 2010
What is Success?
Ok, not a thought on software. But this is a thought on life. I've been trolling my usual websites and came across an interesting article on a man who dumbed himself down to get a job (left his Master's Degree of his resume, and pretended to be fratboy-ish during the interview to relate to the interviewer). Wait, about fratboy-ish - I was in a frat in college, so I can say that.
Well he succeeded and landed the job. Surprise surprise, he was way overqualified and it drove him crazy. This led to a discussion on how to be successful, which begs the question: what is success?
This can't be a new topic. Have people my age given this much thought? Are our only connotations of success those of our previous generation's, that being a good job at a good company with a good family and a good home? And yes, I can see the argument that those criteria equals success - but what does "good" mean?
It's different strokes for different folks. A "good" job for someone else is torture for another. It's entirely subjective. I grew up in middle-class Long Island in the late 80s and 90s. There were big shiny office buildings everywhere. I grew up with the notion that to be a success in life was to have those things - the job in the shiny office building, an abundant income, and some material luxuries to illustrate the point.
Now, however, my idea of success is much different. The only commonality about success is that it's different for everyone. Every person (yes, every person) is different, and every person's goals are different. Therefore, the definitions of success are different for everybody.
Furthermore, I don't think success has anything to do with what surrounds you, what job you have, how your house looks, etc. For whichever job you want to have, or however you want it to look, accomplishing those things doesn't mean you are a success.
I believe success (ha! And based on what I just said, this could only apply to me) is being something. Not just anything - but being who you are. I believe that success is accomplishing whatever you came here (here = planet Earth; yes, I believe in that stuff) to accomplish.
For me, this has been the greatest challenge of my life so far (besides Statisics at UAlbany). Having spent much of my early teens and on altering how I acted to fit in, so much so that I completely lost myself, the challenge has been reversing course and peeling away the misconceptions that I picked up along the way. It's simple and it's not at the same time. I suppose it's as hard as I want to make it.
And previously I had thought that everyone's success is along this vein - about being one's self. Then I realized, that by my definition of success, that it's different for everyone and this may be my particular success, not anyone else's. It also helps to realize once in a while, and it feels really freeing, that in general, that I know absolutely nothing :) (and neither do you)
Well he succeeded and landed the job. Surprise surprise, he was way overqualified and it drove him crazy. This led to a discussion on how to be successful, which begs the question: what is success?
This can't be a new topic. Have people my age given this much thought? Are our only connotations of success those of our previous generation's, that being a good job at a good company with a good family and a good home? And yes, I can see the argument that those criteria equals success - but what does "good" mean?
It's different strokes for different folks. A "good" job for someone else is torture for another. It's entirely subjective. I grew up in middle-class Long Island in the late 80s and 90s. There were big shiny office buildings everywhere. I grew up with the notion that to be a success in life was to have those things - the job in the shiny office building, an abundant income, and some material luxuries to illustrate the point.
Now, however, my idea of success is much different. The only commonality about success is that it's different for everyone. Every person (yes, every person) is different, and every person's goals are different. Therefore, the definitions of success are different for everybody.
Furthermore, I don't think success has anything to do with what surrounds you, what job you have, how your house looks, etc. For whichever job you want to have, or however you want it to look, accomplishing those things doesn't mean you are a success.
I believe success (ha! And based on what I just said, this could only apply to me) is being something. Not just anything - but being who you are. I believe that success is accomplishing whatever you came here (here = planet Earth; yes, I believe in that stuff) to accomplish.
For me, this has been the greatest challenge of my life so far (besides Statisics at UAlbany). Having spent much of my early teens and on altering how I acted to fit in, so much so that I completely lost myself, the challenge has been reversing course and peeling away the misconceptions that I picked up along the way. It's simple and it's not at the same time. I suppose it's as hard as I want to make it.
And previously I had thought that everyone's success is along this vein - about being one's self. Then I realized, that by my definition of success, that it's different for everyone and this may be my particular success, not anyone else's. It also helps to realize once in a while, and it feels really freeing, that in general, that I know absolutely nothing :) (and neither do you)
Thursday, July 22, 2010
Say It Ain't So, Google
Please, no. I've been a huge Google fan since I found it in the late 90s. I remember hearing about and trying Google as a search engine, and instantly saw how much better the results were. It wasn't even close. From then on, Google has been my primary search engine and my homepage. I try other engines once in while, but the staggering difference in usable results always sends me right back to Google.
I've loved that Google has kept their page simple. Just the big search box and their name. While search results are important, having the clean interface (unlike MSN and YAHOO) is just nicer to look at.
Then came some more links on Google's homepage. Ok, that's fine. I understand they have business and advertising solutions. Then came some more - ok, ok, fine. They have Google labs, new products, tools, news services, fine. Actually, for the amount of content and tools they have, the interface is still relatively uncluttered.
Then came... privacy concerns? C'mon Google. And Eric Schmidt's quote: "If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.” Ouch. That sounds a little closer to evil than I thought Google would ever be. Not a terrible quote, but doesn't quite leave me feeling warm and fuzzy about Google.
Then came the hideous background day. What were they thinking? Forcing content on their users? Eliminating choice? Thankfully, they rescinded this decision, but the damage was done. Google appears to be changing their ways.
Finally, the new Google News layout - which is confusing and crappy. Not to mention that the stories on the page keep moving up and down on my screen as the page loads. They took what was a great, easy-to-use layout, and tinkered with it leaving it worse than it was before. This doesn't sound like the Google I know at all.
What's happening over there? Is this what we can expect from Googleland? Say it ain't so, Google. Say it ain't so.
In their defense, however: I am still quite thankful for their blogger software!! And their search engine results are still, by far, second to none. For that, I say thank-you.
I've loved that Google has kept their page simple. Just the big search box and their name. While search results are important, having the clean interface (unlike MSN and YAHOO) is just nicer to look at.
Then came some more links on Google's homepage. Ok, that's fine. I understand they have business and advertising solutions. Then came some more - ok, ok, fine. They have Google labs, new products, tools, news services, fine. Actually, for the amount of content and tools they have, the interface is still relatively uncluttered.
Then came... privacy concerns? C'mon Google. And Eric Schmidt's quote: "If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.” Ouch. That sounds a little closer to evil than I thought Google would ever be. Not a terrible quote, but doesn't quite leave me feeling warm and fuzzy about Google.
Then came the hideous background day. What were they thinking? Forcing content on their users? Eliminating choice? Thankfully, they rescinded this decision, but the damage was done. Google appears to be changing their ways.
Finally, the new Google News layout - which is confusing and crappy. Not to mention that the stories on the page keep moving up and down on my screen as the page loads. They took what was a great, easy-to-use layout, and tinkered with it leaving it worse than it was before. This doesn't sound like the Google I know at all.
What's happening over there? Is this what we can expect from Googleland? Say it ain't so, Google. Say it ain't so.
In their defense, however: I am still quite thankful for their blogger software!! And their search engine results are still, by far, second to none. For that, I say thank-you.
Thursday, July 8, 2010
Motivation Matters (We're Not in the 50s Anymore)
I read a good article on another blog today that described how it is important to sell the product to the developers of it first (Link to original article). How very true!
In general, motivation really matters! Do the developers have faith in the product? Do the developers have faith in the company? I believe this makes a very big difference. Yes, you can certainly make the argument that a developer's paycheck is all the motivation that is needed. But the reality of today is that people expect more.
This isn't our parent's or grandparent's generation anymore. My grandfather grew up in a poor family and lived through the Depression. Money was tight, and saving it was important. I still remember how he'd swipe the extra ketchup packets from McDonalds and stash them in his fridge. So for them, to even have a job with a paycheck was all the motivation that was necessary.
The reality for this generation (at least this generation of IT people and software developers, since the demand is quite high) is that we need more than a paycheck to produce at our highest level. Yes, solid developers will always produce - motivated or not. That's just good discipline and professionalism.
But do you want to get the best out of your developers? Their heart has to be in it. The developers have to get their emotions involved - they have to feel it. They have to believe not only in the product, but in the company and the leadership. In general, to get the best and the highest out of a developer and a team, you need all of these things PLUS a developer who truly enjoys writing code. You need COMPLETE alignment with all of these aspects to bring the highest level of production from your developers and development team.
Yes, I understand this may sound spoiled. I do, as a matter of fact, take time to think every day how thankful I am for my current job and all it has given to me (far too much to mention here - but to name a few: house, food, dogs, etc). But if you are a moderate or above-skilled software developer, you are most likely in demand. Money is fairly good, and at that point, other factors come into play.
Consider the alternative situation - a developer who's happy to get a paycheck, but subconsciously does not like the company or the leadership. Do you think that will find its way into the work? Yes! Do you think the negative attitude might affect others on the team? Yes! Alignment on all fronts is the best way to have a highly motivated, highly productive software team.
In general, motivation really matters! Do the developers have faith in the product? Do the developers have faith in the company? I believe this makes a very big difference. Yes, you can certainly make the argument that a developer's paycheck is all the motivation that is needed. But the reality of today is that people expect more.
This isn't our parent's or grandparent's generation anymore. My grandfather grew up in a poor family and lived through the Depression. Money was tight, and saving it was important. I still remember how he'd swipe the extra ketchup packets from McDonalds and stash them in his fridge. So for them, to even have a job with a paycheck was all the motivation that was necessary.
The reality for this generation (at least this generation of IT people and software developers, since the demand is quite high) is that we need more than a paycheck to produce at our highest level. Yes, solid developers will always produce - motivated or not. That's just good discipline and professionalism.
But do you want to get the best out of your developers? Their heart has to be in it. The developers have to get their emotions involved - they have to feel it. They have to believe not only in the product, but in the company and the leadership. In general, to get the best and the highest out of a developer and a team, you need all of these things PLUS a developer who truly enjoys writing code. You need COMPLETE alignment with all of these aspects to bring the highest level of production from your developers and development team.
Yes, I understand this may sound spoiled. I do, as a matter of fact, take time to think every day how thankful I am for my current job and all it has given to me (far too much to mention here - but to name a few: house, food, dogs, etc). But if you are a moderate or above-skilled software developer, you are most likely in demand. Money is fairly good, and at that point, other factors come into play.
Consider the alternative situation - a developer who's happy to get a paycheck, but subconsciously does not like the company or the leadership. Do you think that will find its way into the work? Yes! Do you think the negative attitude might affect others on the team? Yes! Alignment on all fronts is the best way to have a highly motivated, highly productive software team.
Friday, June 25, 2010
9-5 Obsolete
This is a quickie, but I have many more thoughts on the subject. For software people, and perhaps other positions and industries as well, the 9-5 workday is not only obsolete, but dysfunctional. I personally find it hard to focus on problem-solving for more than 3 hours at a time, and require a solid 1-2 hour break to maintain maximum efficiency when I code.
I've read and observed a movement towards the loosening of the developer's 9-5 schedule. In fact, companies are finding that there are advantages to flexible schedules that result in better customer service and overall competitive advantages. For one (of many) examples, checkout the link to Chris Ashworth's blog below:
I've read and observed a movement towards the loosening of the developer's 9-5 schedule. In fact, companies are finding that there are advantages to flexible schedules that result in better customer service and overall competitive advantages. For one (of many) examples, checkout the link to Chris Ashworth's blog below:
Data Structures for Data Processing
I'm sort of thinking out loud here - but this is a compare/contrast of two ways of handling data on a form. Recently, I've completed two web applications, both of which were the electronic web-forms of what were paper medical forms. I took two distinct approaches to handling the data on the client side (in the browser).
In the first form, I held all data inside a structure. The user would enter the data in textboxes, dropdown lists, etc, and when clicking the “save” button, the first thing my code would do is gather up all the data into a data structure. I did this so that when it came time to do any kind of processing on the data, I’d have a structure that I could easily parse through. So all parsing/interrogations of the data could be done with loops, thereby saving valuable coding time. Similarly, when the form loaded up, I grabbed data from the database and put it in the data structure – then delivered it to wherever it needed to go on the form (back into the correct textboxes, and so on).
In the second form, I avoided this approach. Instead, all data going to and from the database is done individually. It just so happened on this form that there was a lot less data to move around, and since designing/implementing a data structure and generic processing engine for the structure would’ve cost more time, I opted to manually move/interrogate data. I estimated that due to the smaller amount of data for this second form, this approach would save me more time in the long run.
What appears to be happening, though, is that the first approach would’ve been better. As us experienced developers know, projects can sometimes be like roller coasters – unexpected twists, turns, speeding up, slowing down, or sometimes outright stoppages. Sometimes scary, sometimes not so much. For the second project, I’ve had to make modifications to how much data is displayed on the form and how it is laid out. With a generic processing engine, doing this would just be a matter of configuration and a few lines of code. But since I chose to explicitly write everything out, I’m now paying the price of extra time in executing these changes. Have I equaled the time I would’ve spent designing a generic solution, like I did in the first example? Yes, I think I have.
So, the moral to this story is that when you’re moving lots of data around, and even if you’re just interrogating it a little, put it in a data structure so that all processing/interrogation can be done with loops. Not only is it worth the extra time, but it’s fun to design the structures and loops themselves. Speaking of time... I’d better get back to moving that code manually.
In the first form, I held all data inside a structure. The user would enter the data in textboxes, dropdown lists, etc, and when clicking the “save” button, the first thing my code would do is gather up all the data into a data structure. I did this so that when it came time to do any kind of processing on the data, I’d have a structure that I could easily parse through. So all parsing/interrogations of the data could be done with loops, thereby saving valuable coding time. Similarly, when the form loaded up, I grabbed data from the database and put it in the data structure – then delivered it to wherever it needed to go on the form (back into the correct textboxes, and so on).
In the second form, I avoided this approach. Instead, all data going to and from the database is done individually. It just so happened on this form that there was a lot less data to move around, and since designing/implementing a data structure and generic processing engine for the structure would’ve cost more time, I opted to manually move/interrogate data. I estimated that due to the smaller amount of data for this second form, this approach would save me more time in the long run.
What appears to be happening, though, is that the first approach would’ve been better. As us experienced developers know, projects can sometimes be like roller coasters – unexpected twists, turns, speeding up, slowing down, or sometimes outright stoppages. Sometimes scary, sometimes not so much. For the second project, I’ve had to make modifications to how much data is displayed on the form and how it is laid out. With a generic processing engine, doing this would just be a matter of configuration and a few lines of code. But since I chose to explicitly write everything out, I’m now paying the price of extra time in executing these changes. Have I equaled the time I would’ve spent designing a generic solution, like I did in the first example? Yes, I think I have.
So, the moral to this story is that when you’re moving lots of data around, and even if you’re just interrogating it a little, put it in a data structure so that all processing/interrogation can be done with loops. Not only is it worth the extra time, but it’s fun to design the structures and loops themselves. Speaking of time... I’d better get back to moving that code manually.
Friday, June 18, 2010
When To Pass and When To Play
A little blurb about pay and work. In deciding what work I need to do and what I should pass off, I think about the amount of time that needs to be put in versus how much output is produced. For example, I spent a few hours debugging a message-sending program. In a few hours, I got it from non-functional to 99% working. One bug was left regarding an erroneous piece of data. I knew enough to see that it would take another few hours to fix, and it's something that a client may never notice or care about. But should it be fixed? Yes, it should.
That's when it gets handed off to a junior developer. Typically paid less, it's a better use of my time to continue focusing on the higher-level development which in and of itself has more value. That's the best use of my time, which as a senior developer, is typically worth more.
I also have to take into account how much time it takes to get the junior developer up to speed. If the JD has been involved in the project and can jump in easily, great, it's a no-brainer. The JD gets assigned the work. If on the opposite end of the spectrum, the developer is "cold" on the project, it may end up being a break-even proposition to pass the work off. Especially if the JD loses time on his/her current project.
I currently have no hard-and-fast rules for making this decision. I know a few basics about time and value, and I use my gut.
That's when it gets handed off to a junior developer. Typically paid less, it's a better use of my time to continue focusing on the higher-level development which in and of itself has more value. That's the best use of my time, which as a senior developer, is typically worth more.
I also have to take into account how much time it takes to get the junior developer up to speed. If the JD has been involved in the project and can jump in easily, great, it's a no-brainer. The JD gets assigned the work. If on the opposite end of the spectrum, the developer is "cold" on the project, it may end up being a break-even proposition to pass the work off. Especially if the JD loses time on his/her current project.
I currently have no hard-and-fast rules for making this decision. I know a few basics about time and value, and I use my gut.
Subscribe to:
Comments (Atom)
