Code for fun (hobby)
-
I've found that developers who program for fun at their off time usually more in-tune with their skills and have broader knowledge. There are developers that would code at work but have other interests out side of work tense to not very deep in their field. Is my observation off?
Your observation is correct. (But, of course, there are exceptions to every rule.)
-
I've seen much the same thing... I think for the sharp ones, they job is because they like to do it, and it's easy to have that job, whereas the other ones learned it in order to do the job, which is a whole different viewpoint.
Yes. Hence I framed the question "Code for fun" as a hobby and not so much as just code outside of work. When one is doing a hobby no about of time or money matters. The passion for hobby is (for me anyway) addicting and as the old saying "practice makes for perfection" -- not sure that is true for coding, but did learn a lot from it.
-
You are conflating skill and interest.. those two things may meet.. but frequently do NOT. In my life, I've met few truly great programmers.. and to date not one of the greats has been a coder outside of work. I DO see folks falling for the 'I code outside of work' machismo like its something to be proud of.. but to me its never translated to someone how is truly great at getting things done with a minimum of complexity, partitions modules based on logical precepts, and keeps things easy to maintain. Those engineering type skills are severely lacking in most programmers.. which is why I keep seeing so many utter messes that must be dealt with. The panacea of programming that most seek is contained in one word: rigor. Rigor is not based on hours/day.. its based on how you think and apply the lessons of engineering. Working tired actually DECREASES rigor.. Just my 2cents.
-
I guess what I really meant to say was the difference between developers with passion versus developers as to hold a job. But I do agree with what you said, rigor with a passion.
I tend to agree. Passion for programming is definitely not required. I wouldn't call myself passionate about programming.. Its what I do to make money.. But I AM passionate about QUALITY. And I bring that passion to whatever I do.. programming included. Its why I always suspicious of folks who say they are passionate about programming. I can understand wanting to learn more.. and do things better.. but to me the goal is HOW I deliver things to others, and how many bugs I do/don't create in the process. And how easy it is to use what I deliver. I saw a write up on another site talking about how Object Oriented Programming is a huge fail and needs to be gotten rid of.. the rant goes on for pages.. and its clear the poor fool completely misses the point. Bad software can be written in any language.. because its the level of rigor we do/don't bring to the table that defines our end product. Some languages make it easier to express that rigor in real terms.. but at the end of the day if I get a job at a company 99% of the time the choice of language is not mine.. which means the only thing I have control over is the processes and thinking required to make programs. That rigor part. That is the end I've been working to my entire life.. and why after 30+ years I create very few bugs and provide value to the organization I'm in.. What I'm always surprised by is how difficult it is to sell rigor to the folks I work with.. I'll get lip service.. but rarely real buy in for it.. and in my experience its a true differentiator...and also the reason so much crap is committed to code (i.e. a LACK of rigor).
-
A very valid point. I have long advocated the use of robust engineering practices to build software (check out some of my tips / articles on here). Software is an engineering discipline, and rigour is at the heart of that discipline. I have worked with many software developers, some good, some not so good. Some of the great ones however didn't have IT as their background. A couple had degrees in philosophy. This meant they could look at problems with a completely different perspective than your died-in-the-wool developer. They also weren't constrained by tradition or "what everyone else is doing". Another great developer I have worked with left school and went straight into IT and eventually into software development. His depth of knowledge was unsurpassed. A great developer therefore isn't necessarily someone who has an IT background or even IT qualifications. It's more about their attitude and how they approach solving a problem, and how well they understand the various tools, technologies and methodologies to solve those problems.
-
I tend to agree. Passion for programming is definitely not required. I wouldn't call myself passionate about programming.. Its what I do to make money.. But I AM passionate about QUALITY. And I bring that passion to whatever I do.. programming included. Its why I always suspicious of folks who say they are passionate about programming. I can understand wanting to learn more.. and do things better.. but to me the goal is HOW I deliver things to others, and how many bugs I do/don't create in the process. And how easy it is to use what I deliver. I saw a write up on another site talking about how Object Oriented Programming is a huge fail and needs to be gotten rid of.. the rant goes on for pages.. and its clear the poor fool completely misses the point. Bad software can be written in any language.. because its the level of rigor we do/don't bring to the table that defines our end product. Some languages make it easier to express that rigor in real terms.. but at the end of the day if I get a job at a company 99% of the time the choice of language is not mine.. which means the only thing I have control over is the processes and thinking required to make programs. That rigor part. That is the end I've been working to my entire life.. and why after 30+ years I create very few bugs and provide value to the organization I'm in.. What I'm always surprised by is how difficult it is to sell rigor to the folks I work with.. I'll get lip service.. but rarely real buy in for it.. and in my experience its a true differentiator...and also the reason so much crap is committed to code (i.e. a LACK of rigor).
Funny, I read that article, but only got pass about 3 paragraphs and I knew the author doesn't know what OOP really is, then I quit reading it. As for buying into rigor, we have a saying in the federal government research sector "You need to add a Dr. in front of your name before people will take you serious." I ran into that every day.
-
Funny, I read that article, but only got pass about 3 paragraphs and I knew the author doesn't know what OOP really is, then I quit reading it. As for buying into rigor, we have a saying in the federal government research sector "You need to add a Dr. in front of your name before people will take you serious." I ran into that every day.
Yeah.. I got further than you, about 3 pages.. before I decided he was ranting about something I don't consider a problem. I personally find OO helps me protect one portion of a larger system from another.. and partition a system reasonably for maintenance.. but I ALSO know what to avoid in OO so that complexity is reduced. To me.. O-O doesn't get in the way.. and is much better than structured programming (which I used in the 80s and early 90s). The issue that author is worried about just isn't an issue. The REAL issue is there is no magic bullet to replace discipline and rigor in programming.. and management doesn't know how to create high quality because most management doesn't have the engineering experience to even know the real goals to create that (how many managers have I met that only were engineers for 5 years.. when in my experience you don't even achieve first level master until 7-10 years?).
-
I've found that developers who program for fun at their off time usually more in-tune with their skills and have broader knowledge. There are developers that would code at work but have other interests out side of work tense to not very deep in their field. Is my observation off?
Unlike others on this thread, I agree with you. My hobby projects have always helped me on the job. They let me experiment before they are in mission critical mode. They let me take the time to learn something, rather than just do what is necessary because the deadline looms. Work will pigeonhole you, bad enough they think you can only do what they have assigned you. It won't necessarily expand your skills for your next job, unless you just want to do only what you have done before, forever. My hobby projects tend to come in handy when management is gearing up to hire consultants or purchase outside modules because they think they don't have onhand staff that knows how to do something. I've saved the companies I've worked for $10's of thousands of dollars on each project for each work project that I was able to demonstrate how the knowledge I learned on a hobby project had direct bearing and was applicable to the problem at hand.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
I've found that developers who program for fun at their off time usually more in-tune with their skills and have broader knowledge. There are developers that would code at work but have other interests out side of work tense to not very deep in their field. Is my observation off?
Well, almost all my coding is as a hobbyist, though I do have some training and I do occasionally write small commercial apps (as favors generally). Indeed, for a long time my hobby was my job and that included coding (amongst other things). My knowledge is certainly not as deep as many professionals, though being a mathematician and scientist gives me strengths in certain specialist applications. Also, My skills are not always highly polished, as I program sporadically (when I have the time)and flitter between technologies. (If I went for an interview I would have to brush up on the specific skills required and wipe off the rust). I do consider my knowledge fairly broad, however, as I am not constrained. I enjoy playing around with C#, Java and C++ mostly and computer graphics and also PHP and Java, so I can hold my own on detailed comparisons between the workings of Java and C# for example. I have also been around for a bit so I remember when assembly language was an essential tool (lol). I remember the rise of OOP and remember coding database applications without it, so I can give a good discourse on the relative pros and cons of each. So, breadth maybe, but not the specific skills and experience most commercial roles require.
-
I've found that developers who program for fun at their off time usually more in-tune with their skills and have broader knowledge. There are developers that would code at work but have other interests out side of work tense to not very deep in their field. Is my observation off?
I used do lots of hobby code, lately, due to time, I off-shore all my hobby coding to India. My code quality since has gone downhill. ;)