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:
Friday, June 25, 2010
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.
Techinline, File Drops, and Mirth
This is just a collection of a few random things I've picked up lately.
Firstly, I used Techinline for remote support today. I was the user being supported, and someone from Canada was working on my computer to install and configure a product (BTW, I like the idea of an installation professional doing this task instead of me trying to follow a set of instructions and troubleshooting. The experience of the professional installer is quite valuable and time-saving).
As an end-user, it was great. Quick and easy to setup and use. The pricing structure for the support people (who are the ones purchasing the product) seemed inexpensive and flexible. What else do you need for a remote support tool?
Secondly, I'm noticing that file drops monitored by services are a popular way to communicate data. Communication of data is ... well... what the Internet age is all about. At it's core, it's about DATA. Data provides the information, information provides the power for growth, expansion, and profitability for your business. I've worked on several products that result in file drops to a directy, and that directory is monitored by a service. The service detects the creation, update, or delete of files in the directory, then takes action based on that. Visual Studio (.NET) provides built-in, easy-to-use classes to implement file-watchers. It's a neat tool, and often a good solution for a data communication need.
Finally, Mirth. Mirth is (surprise, surprise) a DATA communication tool. And a good one. Here, they say it best themselves:
"Enter Mirth Connect, the Swiss Army knife healthcare integration engine. Specifically designed for HL7 message integration, Mirth provides the necessary tools for developing, testing, deploying, and monitoring interfaces."
Mirth is able to poll databases, poll directories, listen for incoming communications, then translate from certain formats to other formats (HL7 and XML to name a couple), and proceed to insert to other databases, drop files elsewhere, and so on, and so on. There's a lot of ways to use Mirth. You can also operate on the data, too.
It's a server-based tool, so you'll setup a "Mirth Server" somewhere. Then you use their client to configure "channels". Channels are just "channels" of data - each channel can read data using whatever method you need, do whatever transformations/interrogations of the data are necessary, then send it onward. You can, of course, have as many channels as you need.
So the bottom line is you can get your data into Mirth any number of ways (the advantage is you can design your solution with more flexibility), you can write code in Mirth (mostly javascript) to operate on the data, then use their built-in data transformers to change formats or whatnot, then send that data on to wherever it needs to go. Very flexible, very handy.
Firstly, I used Techinline for remote support today. I was the user being supported, and someone from Canada was working on my computer to install and configure a product (BTW, I like the idea of an installation professional doing this task instead of me trying to follow a set of instructions and troubleshooting. The experience of the professional installer is quite valuable and time-saving).
As an end-user, it was great. Quick and easy to setup and use. The pricing structure for the support people (who are the ones purchasing the product) seemed inexpensive and flexible. What else do you need for a remote support tool?
Secondly, I'm noticing that file drops monitored by services are a popular way to communicate data. Communication of data is ... well... what the Internet age is all about. At it's core, it's about DATA. Data provides the information, information provides the power for growth, expansion, and profitability for your business. I've worked on several products that result in file drops to a directy, and that directory is monitored by a service. The service detects the creation, update, or delete of files in the directory, then takes action based on that. Visual Studio (.NET) provides built-in, easy-to-use classes to implement file-watchers. It's a neat tool, and often a good solution for a data communication need.
Finally, Mirth. Mirth is (surprise, surprise) a DATA communication tool. And a good one. Here, they say it best themselves:
"Enter Mirth Connect, the Swiss Army knife healthcare integration engine. Specifically designed for HL7 message integration, Mirth provides the necessary tools for developing, testing, deploying, and monitoring interfaces."
Mirth is able to poll databases, poll directories, listen for incoming communications, then translate from certain formats to other formats (HL7 and XML to name a couple), and proceed to insert to other databases, drop files elsewhere, and so on, and so on. There's a lot of ways to use Mirth. You can also operate on the data, too.
It's a server-based tool, so you'll setup a "Mirth Server" somewhere. Then you use their client to configure "channels". Channels are just "channels" of data - each channel can read data using whatever method you need, do whatever transformations/interrogations of the data are necessary, then send it onward. You can, of course, have as many channels as you need.
So the bottom line is you can get your data into Mirth any number of ways (the advantage is you can design your solution with more flexibility), you can write code in Mirth (mostly javascript) to operate on the data, then use their built-in data transformers to change formats or whatnot, then send that data on to wherever it needs to go. Very flexible, very handy.
Tuesday, June 15, 2010
How To Be Your Most Effective
Alright, this isn't the end-all be-all self-help type article. Let's get that out of the way. This advice/observation, just like all pieces of advice and observation, don't apply to all people at all times. But for those who are reading this that have found it, and it applies to you hook-line-and-sinker - awesome. Thanks for stopping by.
I began thinking about this topic over the last year. In a way, I've been thinking about it since the beginning of my software development career. Having been an over-achiever during my years in schooling, I expected to be the same over-achiever once I got into the work-force. And actually, I was during my stint in real estate and at times during my software developing. I had this feeling, though, that I was destined for something greater. Now when I say "greater", I mean "greater for myself." What is great for me is NOT great for someone else. Is it ever? I don't think life is a one-size-fits-all proposition.
I began a more intensive study of computer science in my spare time, reading as much as I could and programming when I could. The thing is, I found this really hard. I'd come home after a long day, I'd be tired, I'd have other responsibilities, and didn't have the drive and motivation to continue my personal studies of programming, software architecture, and so on. I soon realized that if I continued in this direction, I would not be a "great" programmer for many many years. There is so much to the art of programming, that much more energy than I had was required to study and learn it.
And there was the key - energy. I see people who excel to great things in their jobs and careers, including programmers, and they have ENERGY. They're excited, passionate, and it comes naturally to them to put in the extra time because IT DOESN'T FEEL LIKE WORK.
From there, I realized that there are other things I do in my life that technically are work, but they don't feel like it. And I'd think about those things and realize not only did I "work" hard, but I felt amazing afterwards.
"Oh," I realized. THIS is what my job/career needs to feel like. It needs to energize me and not feel like work. Now, since yardwork is not a career option at this point (and believe it or not, I love doing yardwork), I thought about other activities that inspire my passion.
Enter my MBA classes. With the study of money, finances, presentations, and groupwork, I found that even after being drained at 5pm from a day at work, my energy would ramp up from 5:30-9 during my classes. THIS, I realized, is what gets me. These kinds of activities are where I need to be (group-work, leading, coordinating, project related work). In this kind of position, with this high an energy level, I can be "great" in my field without it feeling like work. That, I believe, is the key to being most effective. Having a profession or occupation that fills you with energy, rather than depleting it.
So, I set out looking for exactly that. I believe I'll get there, too; my level of enthusiasm is too high for this to stay off my radar. I'm excited at the prospect of having this new kind of career and job experience, and know I'll be a boon to whichever organization can put me in this role.
I began thinking about this topic over the last year. In a way, I've been thinking about it since the beginning of my software development career. Having been an over-achiever during my years in schooling, I expected to be the same over-achiever once I got into the work-force. And actually, I was during my stint in real estate and at times during my software developing. I had this feeling, though, that I was destined for something greater. Now when I say "greater", I mean "greater for myself." What is great for me is NOT great for someone else. Is it ever? I don't think life is a one-size-fits-all proposition.
I began a more intensive study of computer science in my spare time, reading as much as I could and programming when I could. The thing is, I found this really hard. I'd come home after a long day, I'd be tired, I'd have other responsibilities, and didn't have the drive and motivation to continue my personal studies of programming, software architecture, and so on. I soon realized that if I continued in this direction, I would not be a "great" programmer for many many years. There is so much to the art of programming, that much more energy than I had was required to study and learn it.
And there was the key - energy. I see people who excel to great things in their jobs and careers, including programmers, and they have ENERGY. They're excited, passionate, and it comes naturally to them to put in the extra time because IT DOESN'T FEEL LIKE WORK.
From there, I realized that there are other things I do in my life that technically are work, but they don't feel like it. And I'd think about those things and realize not only did I "work" hard, but I felt amazing afterwards.
"Oh," I realized. THIS is what my job/career needs to feel like. It needs to energize me and not feel like work. Now, since yardwork is not a career option at this point (and believe it or not, I love doing yardwork), I thought about other activities that inspire my passion.
Enter my MBA classes. With the study of money, finances, presentations, and groupwork, I found that even after being drained at 5pm from a day at work, my energy would ramp up from 5:30-9 during my classes. THIS, I realized, is what gets me. These kinds of activities are where I need to be (group-work, leading, coordinating, project related work). In this kind of position, with this high an energy level, I can be "great" in my field without it feeling like work. That, I believe, is the key to being most effective. Having a profession or occupation that fills you with energy, rather than depleting it.
So, I set out looking for exactly that. I believe I'll get there, too; my level of enthusiasm is too high for this to stay off my radar. I'm excited at the prospect of having this new kind of career and job experience, and know I'll be a boon to whichever organization can put me in this role.
Monday, June 14, 2010
Leading Off
Ok, this is not about actual software development. It was only a matter of time before I started delving into non-software topics. But this is my writing outlet, and it's a reflection of my life. If I need to at some point, I'll change it to "Thoughts on Software...and Life...and Other Stuff."
Tomorrow for my public speaking class (I'm an MBA student at the University of Albany in NY), my group is giving a presentation on salary caps in Major League Baseball. We are the first group to go that day. I, personally, am the first speaker in our group handling the introduction. I was very happy, when by luck of the draw, our group was chosen to go first. I also specifically wanted to present first.
Why? I think it's because I like to set the tone. I like to take the initiative and shape whatever event/experience is occurring. One of the things I've become much better at is doing this while giving slack elsewhere - which is quite conducive to a successfully functioning groups. My inclination in the past was not only to set the tone, but control the tone. I have thankfully since learned the art of working with and guiding a group, while at the same time knowing when to lay off the reins and let others guide. This art and this approach seems to be the best way to get the most out of the groups I work with.
I've learned, actually, that there is a real beauty and peace in NOT controlling (well, attempting to control) a group, its work, and its direction. Looking back on groups where I did this, my experiences were stressful and negative. It left me with a distaste for groupwork, and the desire to work alone. HA!! Maybe that's how I became a programmer.
Anyway, I do not believe I'll be directly involved in programming much longer. Leadership, management, coordination, and communcation have always been strong points of mine (or some at least points with massive undeveloped potential), and I'm finally at a point in my life where I have the foundation to move in that direction.
To get to this point, I had to shed my desire to work alone - which is basically what a lot of programmers want. I've gotten to a point where I realize that my potential in the leadership and management areas FAR exceeds my potential as a technical professional. One of the major signs of this realization was how much I enjoyed working in, guiding, and coordinating projects of all kinds (both as a software developer and an MBA student). I saw that if my job energized me, and made me feel good, I'll be able to contribute magnitudes more in that position than doing something else. So, I now seek this kind of position.
And if I get it - Thoughts On Software may have to change. Thoughts On Leadership?
Tomorrow for my public speaking class (I'm an MBA student at the University of Albany in NY), my group is giving a presentation on salary caps in Major League Baseball. We are the first group to go that day. I, personally, am the first speaker in our group handling the introduction. I was very happy, when by luck of the draw, our group was chosen to go first. I also specifically wanted to present first.
Why? I think it's because I like to set the tone. I like to take the initiative and shape whatever event/experience is occurring. One of the things I've become much better at is doing this while giving slack elsewhere - which is quite conducive to a successfully functioning groups. My inclination in the past was not only to set the tone, but control the tone. I have thankfully since learned the art of working with and guiding a group, while at the same time knowing when to lay off the reins and let others guide. This art and this approach seems to be the best way to get the most out of the groups I work with.
I've learned, actually, that there is a real beauty and peace in NOT controlling (well, attempting to control) a group, its work, and its direction. Looking back on groups where I did this, my experiences were stressful and negative. It left me with a distaste for groupwork, and the desire to work alone. HA!! Maybe that's how I became a programmer.
Anyway, I do not believe I'll be directly involved in programming much longer. Leadership, management, coordination, and communcation have always been strong points of mine (or some at least points with massive undeveloped potential), and I'm finally at a point in my life where I have the foundation to move in that direction.
To get to this point, I had to shed my desire to work alone - which is basically what a lot of programmers want. I've gotten to a point where I realize that my potential in the leadership and management areas FAR exceeds my potential as a technical professional. One of the major signs of this realization was how much I enjoyed working in, guiding, and coordinating projects of all kinds (both as a software developer and an MBA student). I saw that if my job energized me, and made me feel good, I'll be able to contribute magnitudes more in that position than doing something else. So, I now seek this kind of position.
And if I get it - Thoughts On Software may have to change. Thoughts On Leadership?
Friday, June 11, 2010
Knowing Why You're Coding
The writer's block is over. Hello again.
I remembered today that it's important to know why you're coding. Ok, so maybe not important to all, as some people code for the joy of coding and solve problems for the joy of solving problems. I'm a bit different on this, which is why it helps to know what the value is of the item I'm creating.
Now the true, absolute value of what one is creating cannot be known. One never knows what the ripple effects will be from the software that is written. I'm thinking in terms of the "butterfly effect", which I truly believe, and if you stop and think about it is truly amazing. That small decisions we make any and every day have multiplicative consequences as time goes by. If you sit and ponder all of the possible good that may come from the software you're writing, then you will understand that the potential value of your creation is LIMITLESS.
However, in this case, I'm talking in terms of value to the customer. How much does the customer want what you're doing (current customers or future customers)? What needs or desires is the software fulfilling? Just how happy will someone be to get to use your software? As a sometimes free-lance developer, I get an immense satisfaction when experiencing a client's excitement for the website I've designed for them.
This all came up today as I struggled through creating a billing add-on to a client's medical software. I didn't quite know the full picture of what I was creating, or how badly the customer wanted it, and what it might do for the customer. When, after a long week, I finally delivered it, my co-worker (who previously handed the project off to me) said, "Feels good, doesn't it?"
I paused. It should've felt good - but it didn't. He then went on to explain how much time this addition will save them, and how much they've been asking for it. OHHHHHHHH. Then it felt good. And then I thought about writing about it here. Knowing I am truly creating value for the customer/client is immensely satisfying as well as motivating. Going forward I recommend we all consider that when undertaking projects. It's easy to disconnect from this human element of it, but the reality is that in most cases we're providing tremendous value to someone somewhere.
AND, this is not even considering the butterfly effects for the client, either. Time saved for a person due to my software translates into... ?? Possibly anything. Hopefully good and joyous. AND, for all the goodness and joy created on down the line that had its roots in the time saved from our software - we developers know we made all of that happen, all the way up the line, for however long it goes. Which is infinite.
All of us, not just developers, are affecting lives and life in this way. In a sense, that makes us all infinite and permanent. I think we're done here. It's nice to be writing after a little layoff.
I remembered today that it's important to know why you're coding. Ok, so maybe not important to all, as some people code for the joy of coding and solve problems for the joy of solving problems. I'm a bit different on this, which is why it helps to know what the value is of the item I'm creating.
Now the true, absolute value of what one is creating cannot be known. One never knows what the ripple effects will be from the software that is written. I'm thinking in terms of the "butterfly effect", which I truly believe, and if you stop and think about it is truly amazing. That small decisions we make any and every day have multiplicative consequences as time goes by. If you sit and ponder all of the possible good that may come from the software you're writing, then you will understand that the potential value of your creation is LIMITLESS.
However, in this case, I'm talking in terms of value to the customer. How much does the customer want what you're doing (current customers or future customers)? What needs or desires is the software fulfilling? Just how happy will someone be to get to use your software? As a sometimes free-lance developer, I get an immense satisfaction when experiencing a client's excitement for the website I've designed for them.
This all came up today as I struggled through creating a billing add-on to a client's medical software. I didn't quite know the full picture of what I was creating, or how badly the customer wanted it, and what it might do for the customer. When, after a long week, I finally delivered it, my co-worker (who previously handed the project off to me) said, "Feels good, doesn't it?"
I paused. It should've felt good - but it didn't. He then went on to explain how much time this addition will save them, and how much they've been asking for it. OHHHHHHHH. Then it felt good. And then I thought about writing about it here. Knowing I am truly creating value for the customer/client is immensely satisfying as well as motivating. Going forward I recommend we all consider that when undertaking projects. It's easy to disconnect from this human element of it, but the reality is that in most cases we're providing tremendous value to someone somewhere.
AND, this is not even considering the butterfly effects for the client, either. Time saved for a person due to my software translates into... ?? Possibly anything. Hopefully good and joyous. AND, for all the goodness and joy created on down the line that had its roots in the time saved from our software - we developers know we made all of that happen, all the way up the line, for however long it goes. Which is infinite.
All of us, not just developers, are affecting lives and life in this way. In a sense, that makes us all infinite and permanent. I think we're done here. It's nice to be writing after a little layoff.
Subscribe to:
Comments (Atom)
