1: Your productivity will vary wildly from day to day. This is normal. Matches my experience. 2: Working more hours means getting less done. Agree - usually. I put a lot of hours in up front to master the tools, the documentation, the technology and the underlying problem space so that I rarely have to work lots of hours to get lots done. Aside from brief stints I find that working lots of hours all the time usually coincides with "fix-break-fix-break" situations. Usually means the devs are in over their head - no one's taking on the task of doing the fundamental redesign needed to break the "fix-break-fix-break" cycle. 3: Working harder means getting less done. Once you've mastered the tools the process of coding becomes very fluid - it just flows out of you. If you're working hard all the time, not just for stints as you encounter something new, then there's a good chance you could work less hard by increasing your mastery of some piece of the puzzle. 4: Procrastination can be good for you No comment! :) 5: Happiness is the ultimate productivity enhancer. Hear Hear!
shea c4
Posts
-
The top 5 new rules of productivity -
CString insertion operator faulty?You have to cast the CString to an LPCTSTR ala
fTest << (LPCTSTR)cstr;So that the insertion operator uses the right overload. If you're using unicode, (e.g., L"This is a test" or, _T("This is a test") and unicode is turned on), then you'll want to use a std::wofstream instead of std::ofstream. But you'll still need to cast cstr to LPCTSTR. If you, like me, tried testing this with cout, try using wcout instead (the cast to LPCTSTR is still required). -
Why C# is hot... cool... whateverIt's wonderful isn't it? The functionality at your fingertips these days is so rich that sometimes it feels like you can get 10 times as much done these days as you could a mere 10 years ago.
-
Ideological Programming Question...I have to sorta object here. If you think of every conditional as doubling (at least) the number of tests required for complete coverage, and estimate that 1/10th of all lines of source are conditionals, then a single method that has 200 lines of code has at least 20 conditions. That's 2^20 variations to test (~million). Add a few more such methods and it quickly becomes entirely infeasible to test every execution path. Testing is critical. Very important. But testing is not a substitute for good coding habits. "Provable Correctness" has not yet found its way into the commercial world and testing is no shortcut to it. Apologies for hijacking this thread!
-
Ideological Programming Question...Before Visual Studio 2005's "Refactor -> Extract Method" I'd have said 200 - 250 lines was pushing it but not worth missing a deadline over. With Extract Method, it's a cinch to go back and move large swaths of code into a method call so it's easier to be a little tighter on the length of a function. I have never gotten to the point where every method is entirely visible on a single page. People who sprang for VisualAssist (or whatever it was called) may have a lower tolerance for long methods.
-
For anyone interested in UI DesignExcellent link, thanks! It's one of the best arguments for Silverlight/WPF-ish UIs I've seen so far. Very easy to use, gets out of the way of conveying the patterns, the UI draws you in almost like it's seducing you into browsing through its contents. I'll have to go through all the patterns this weekend. Too good to miss!
-
DSL vs. CableI've got DSL (6Mbps down) and have no real complaints. The service has been rock solid. In the past 5 years there has been a DSL related outage maybe twice. I can't comment on customer support because I've never used it. Besides, I like the separation of having the internet delivered over the phone while cable/HD/on-demand are delivered over cable. Cable has gotten better in terms of reliability but it still goes out more often than my DSL connection. With separate connections at least the internet is available when the cable is out. Now if only the power company were as reliable as the phone company....
-
Efficient way of accessing a Boolean from SQL ServerYou could also use:
bool isValid = Convert.ToBoolean(SqlCommand.ExecuteScalar());I'd probably have usedselect @Valid = [Valid] FROM tUsers WHERE ID=@IDBut what you have is fine. Lastly, you may want to use ParameterDirection.Output for the @Valid parameter since there isn't a value being passed in... -
Adventures in development on a Virtual Machine chapter 10...I'll have to check out VirtualBox. Does it support DirectX in the virtual machines? Virtual PC doesn't. Lack of DirectX support heavily undermined my campaign to convince co-workers of the virtues of virtual machines.
------------------ MCAD.net, MSc (CS)
-
Do you use dual Monitor for CodingGlad to see a boss out there that understands the concentration/focus it takes to do things well. I would be more distracted if I had email up on a second window; the desktop alert (fade-in/fade-out notification) is bad enough. I'll often turn it off temporarily if working on a particularly nasty issue (or under the gun for quick turn around). I'd say that the biggest benefit to the 2nd monitor is documentation with debugging a close second. The more I use the documentation the easier it gets to use. That translates into much greater productivity because I spend a lot less time reinventing the wheel. Less time reinventing the wheel means more time spent getting "the meat" of the project right (or at least better). There are millions of lines of code out there to do a lot of the mundane aspects of any project that never get used because developers never read the documentation. Who wants to have to interrupt what their doing to open the docs? When the docs are always open, you don't have this problem. When developers re-write things that have already been written, you're paying them to reinvent the wheel. That impacts the bottom line.
------------------ MCAD.net, MSc (CS)
-
Do you use dual Monitor for CodingYes, I have for years and shudder at the thought of coding without it. #1 benefit is documentation. I leave local copies of MSDN maximized on the second monitor. Other benefits: - makes finding the "right" API call a snap - makes it easier to figure out where to put an API call or code sample since Visual Studio is maximized on the primary monitor. - makes tracing through log files easier (ultraedit on the secondary, visual studio on the primary) - great for reading through the extra technical articles that come bundled with MSDN while some long running install, uninstall, compile, etc... is running on the primary monitor. - great for matching up the UI to spec screenshots. - great for ripping code out of the platform SDK by having visual studio open on both monitors (my project on primary, the code sample on the secondary). - great for working through any kind of tutorial or walkthrough (browser in second window, visual studio in primary window). It's a big part of why I'm so much more productive (codewise at least) than you single monitor types (j/k people, much love to all coders!) ;)
------------------ MCAD.net, MSc (CS)
-
MSDN2 rant of the dayMSDN & MSDN2 are awesome. So much more useful than man pages that they're in an entirely separate league. At the top of the page you've got each node in the MSDN documentation tree to the current page. Click on the class itself (CStringT Class) then go to remarks. Now that I think about it, that's kind of a pain. The .NET docs are so much better :)
arnshea, MCAD.net, MSc (CS)