After reading this, I felt compelled to compile some of the similar thoughts from here and put together a short blurb on what it's like for me, being a programmer.
I do find myself writing code in a sprinting fashion. I can always code when it's time, but sometimes I get a burst of speed and clarity that I might not have every single day. I sprint ahead and make up for the days when I'm not so sharp. Many programmers do this. Programming is hard, and it's easy to get distracted. As a programmer, I have honed my ability to focus, almost in a meditative state, while I write code. While I'm in this meditative state, I'll have dozens of pieces of my code visualized in my head, potentially solving multiple 'problems' at once related to the project. I'll also have the overall path of the project and the various smaller tasks I could potentially be working on visualized. Getting distracted while in this state is the equivalent to someone walking up to my mental whiteboard and erasing everything on it. For this reason, when I'm distracted it takes additional time to regain my previous state of concentration and clarity. It takes time to reload into my active thought process all the pieces to the project I'm working on. For this reason, it is imperative to retain my focus while coding.
I do believe this 'mental sprinting' changes with age. Years ago, coding 12 hours a day for weeks on end was not difficult to pull off. The catch was that a very high percentage of the code I wrote, was either poorly written or bug-ridden and easily could have been written in far less time had I spent more time thinking about the code before I wrote it. As I've gotten older and gained more coding experience, I've found that it's easier to spend a large amount of time contemplating the code, and then writing the code in shorter bursts. The difference is that when I write code this way, far less hours are wasted.
Our minds naturally work in a cyclical nature. Sometimes I'll get excited about a project or idea and I'll want to work sixteen hours a day on it. Other times, nothing seems interesting. To write quality code and keep my efficiency up, I take these cycles into account. I've discovered they're affected by how I react to them. I keep a cache of easy tasks that are part of the larger project, so that when my mental cycle is at a lull, instead of trying to force difficult code out, I can give my mind a rest and perform easy tasks. Debugging code is great for this. Debugging is as straightforward as most people think programming is. The problem is completely constrained, and all I have to do is troubleshoot it. It's almost relaxing. When my mental cycle is at a peak, I'll perform coding bursts up to 16hrs a day. Generally this does not last more than a few days before I start feeling mentally 'burned out.' By working with these mental cycles, I'm able to keep my coding efficiency as high as possible.
I do find that with some projects, I can write code like a mad man much more easily. Others are painfully slow dredging, and I have great difficulty focusing on them. There are also times where I'll spend hours looking at a problem and just can't seem to make any progress on it because I have a degradation of clarity in visualizing the problem or best solution. Because of this, it can vary greatly how productive I am when I write code. I could spend 40+ on one of those mad man sprints, or a much more painful 15 hours of slow dredging.
I've taken all of this knowledge and experience into account and now my plan is, that when I reach 90, I'll just wake up in the morning and fart.
My very lengthy and heavily customized script will analyze the fart and translate it into C++.
"Oh, boy, I wrote another new Oper
I'm the Senior SysAdmin for a large datacenter in Florida. We currently employ over 50 people in our building.
We recently migrated from Pidgin+OTR(Encryption) to OpenFire+Spark with ActiveDirectory Integration. I had the server installed and pulling down a list of accounts from the AD server in a matter of minutes. The server has worked flawlessly for us for months and has tons of options. It supports the ability to either allow or lock out 'other' clients(AIM,YIM,etc). This coupled with ACL or Firewall restrictions will ensure that your users are ONLY using the Spark client.
It also has chatrooms built into it which you can force your users into when they log on. It's pretty neat stuff.. oh.. it supports SSL connections, and will provide LiveChat for your website as well. It also support logging of all chat conversations if you have a need for that.
The only downside that I've run into.. there's a bug on the linux client that has to be fixed manually(associated with the tray icon not showing up). The Windows client has a tendency to run slightly slow. While I read that it runs slow under Windows, in practicality I have not received even one complaint regarding the use of Spark. Oh.. while there is a history in the Spark client, it shows it all as one realllly long page so it's a little clunky having to hunt through your own personal chat history.
Look no further. OpenFire+Spark is your answer.
Slashdot Mirror
http://www.homeofpoi.com/ There are regular meetups all over and likely one near you.
After reading this, I felt compelled to compile some of the similar thoughts from here and put together a short blurb on what it's like for me, being a programmer.
Programming is Mental Sprinting
Written by: Maxwell Rathbone
Pieces Compiled from: http://ask.slashdot.org/story/10/04/14/1925218/How-Many-Hours-a-Week-Can-You-Program
I do find myself writing code in a sprinting fashion. I can always code when it's time, but sometimes I get a burst of speed and clarity that I might not have every single day. I sprint ahead and make up for the days when I'm not so sharp. Many programmers do this. Programming is hard, and it's easy to get distracted. As a programmer, I have honed my ability to focus, almost in a meditative state, while I write code. While I'm in this meditative state, I'll have dozens of pieces of my code visualized in my head, potentially solving multiple 'problems' at once related to the project. I'll also have the overall path of the project and the various smaller tasks I could potentially be working on visualized. Getting distracted while in this state is the equivalent to someone walking up to my mental whiteboard and erasing everything on it. For this reason, when I'm distracted it takes additional time to regain my previous state of concentration and clarity. It takes time to reload into my active thought process all the pieces to the project I'm working on. For this reason, it is imperative to retain my focus while coding.
I do believe this 'mental sprinting' changes with age. Years ago, coding 12 hours a day for weeks on end was not difficult to pull off. The catch was that a very high percentage of the code I wrote, was either poorly written or bug-ridden and easily could have been written in far less time had I spent more time thinking about the code before I wrote it. As I've gotten older and gained more coding experience, I've found that it's easier to spend a large amount of time contemplating the code, and then writing the code in shorter bursts. The difference is that when I write code this way, far less hours are wasted.
Our minds naturally work in a cyclical nature. Sometimes I'll get excited about a project or idea and I'll want to work sixteen hours a day on it. Other times, nothing seems interesting. To write quality code and keep my efficiency up, I take these cycles into account. I've discovered they're affected by how I react to them. I keep a cache of easy tasks that are part of the larger project, so that when my mental cycle is at a lull, instead of trying to force difficult code out, I can give my mind a rest and perform easy tasks. Debugging code is great for this. Debugging is as straightforward as most people think programming is. The problem is completely constrained, and all I have to do is troubleshoot it. It's almost relaxing. When my mental cycle is at a peak, I'll perform coding bursts up to 16hrs a day. Generally this does not last more than a few days before I start feeling mentally 'burned out.' By working with these mental cycles, I'm able to keep my coding efficiency as high as possible.
I do find that with some projects, I can write code like a mad man much more easily. Others are painfully slow dredging, and I have great difficulty focusing on them. There are also times where I'll spend hours looking at a problem and just can't seem to make any progress on it because I have a degradation of clarity in visualizing the problem or best solution. Because of this, it can vary greatly how productive I am when I write code. I could spend 40+ on one of those mad man sprints, or a much more painful 15 hours of slow dredging.
I've taken all of this knowledge and experience into account and now my plan is, that when I reach 90, I'll just wake up in the morning and fart. My very lengthy and heavily customized script will analyze the fart and translate it into C++. "Oh, boy, I wrote another new Oper
I'm the Senior SysAdmin for a large datacenter in Florida. We currently employ over 50 people in our building. We recently migrated from Pidgin+OTR(Encryption) to OpenFire+Spark with ActiveDirectory Integration. I had the server installed and pulling down a list of accounts from the AD server in a matter of minutes. The server has worked flawlessly for us for months and has tons of options. It supports the ability to either allow or lock out 'other' clients(AIM,YIM,etc). This coupled with ACL or Firewall restrictions will ensure that your users are ONLY using the Spark client. It also has chatrooms built into it which you can force your users into when they log on. It's pretty neat stuff.. oh.. it supports SSL connections, and will provide LiveChat for your website as well. It also support logging of all chat conversations if you have a need for that. The only downside that I've run into.. there's a bug on the linux client that has to be fixed manually(associated with the tray icon not showing up). The Windows client has a tendency to run slightly slow. While I read that it runs slow under Windows, in practicality I have not received even one complaint regarding the use of Spark. Oh.. while there is a history in the Spark client, it shows it all as one realllly long page so it's a little clunky having to hunt through your own personal chat history. Look no further. OpenFire+Spark is your answer.