tag:blogger.com,1999:blog-1528805174514452404.post4700766631911931737..comments2024-03-27T17:10:25.297-04:00Comments on Allen Conway: To take thy code personally - Yes or No? That is the question...Allen Conwayhttp://www.blogger.com/profile/07010967958393033081noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-1528805174514452404.post-34798679683405000862014-09-18T11:02:53.079-04:002014-09-18T11:02:53.079-04:00Gerald M. Weinberg promoted "egoless programm...Gerald M. Weinberg promoted "egoless programming" in 1971. Used this advice myself for over 25 years. Seems a paradox that programming is a solitary activity assigned to teams, and code usually improves when shared. A good edition is ref: Psychology of Computer Programming: Silver Edition ISBN 10: 0932633420 / 0-932633-42-0 ISBN 13: 9780932633422 wherin Mr. Weinberg offers current (1998) comments on his original chapters. Useful lines of thinking, which I largely endorse, though my closely held view is still that the most successful egoless projects have been those that embraced my ideas. No paradox there.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1528805174514452404.post-55910647350192079322014-09-05T17:01:51.911-04:002014-09-05T17:01:51.911-04:00Hello 'anonymous' ;) Nice to hear from you...Hello 'anonymous' ;) Nice to hear from you. I appreciate the comments and feedback.<br /><br />Please remember that the title of the post and overall message is about taking ones 'code' personally, and not anything about passion for one’s craft or profession or about a company’s success to create great and innovative software. I added some clarification to this point and added a link that spawned this post from the 'Grumpy Programmer'. However, it’s a good conversation so I’ll follow the tangent. :D<br /><br />I have had the wonderful opportunity to see this industry through a realm of glasses and different perspectives so please understand my views tend to be 'generic' to the industry and a craft as a whole. My experiences reflect the varying business lines and individuals I've interacted with over the years. While I respect your feedback, I believe it’s heavily shaped from a particular industry and not necessarily the craft generically as a whole. When I blog, I prefer to look at these views on whole and recognize clearly what works for one shop/culture/industry/team will not necessarily hold water in another. It's my job too as well to be like this.<br /><br />The ability to be a chameleon of sorts to adapt is critical to be a great developer or even company. For example from a technology standpoint, most of the industry wouldn't touch WinForms at this point with a 10' pole, and others it's their bread and butter. Doesn't mean using it is 'wrong' just that it needs to be bumped up against the industry and culture for which it is written. It may be completely appropriate but also needs to at least be evaluated for change to remain competitive. The ‘business constraints’ you mention are very different between industries. In some industries the ‘business constraints’ is that if they don’t remain current and modern, they will be yesterday’s news (i.e. MySpace, Yahoo Auctions, etc.) and out of business. Financial, Health, Government, etc. industries are known to have dinosaurs of applications written in COBOL, C++, etc. that live 10’s of years. This is quite different from those that need a competitive edge from their software output and can’t rely on their industry being ‘slow to progress.’<br /><br />Trying to predict the future in this industry is just not feasible; no one has a crystal ball. For example - what is the future? HTML5, JavaScript, Native, Xamarin, PhoneGap, etc.? There are ways to make sound decisions based on experiences but trying to predict is tough to do. There's a significant chance those that are looking backward trying to maintain legacy applications to survive for 5-10 down the road will lose their competitive edge because of rapid technology changes. Those trying to predict the future, will be left in the dust as well with the chance that a technology or platform they placed all their eggs into no longer exists or didn't pan out. It’s certainly a balance of both. At a minimum we should all try and take queue from the industry as a whole as to the winds of change and direction rather than trying to script/predict the future in a vacuum.<br /><br />The comments here went on a tangent to follow your tangent a bit. My main point was to bring things a bit closer to home about the developer/engineer and their relationship with code. One common trait I believe that developers of any line should follow is that taking lines of code personally is not a good path to follow. This advice is shared not just by me, but a lot that have fought on the battle lines of software engineering over the years. I will not correlate being offended by retired code, to being able to create great software in the future. I do agree totally that the best developers are the ones that have passion about their craft (like you and I my friend)… but also at the same time don’t take their code personally.<br /><br />This conversation would have made for an awesome podcast!Allen Conwayhttps://www.blogger.com/profile/07010967958393033081noreply@blogger.comtag:blogger.com,1999:blog-1528805174514452404.post-33524463175669543682014-08-27T08:29:45.090-04:002014-08-27T08:29:45.090-04:00Totally agree with the post, well at least certain...Totally agree with the post, well at least certain aspects... <br /><br />Applications will live and die over time this is a fact and no arguing that point. I believe different individuals gain different experiences from developing applications. Speaking as a purist developer who cares about nothing more than coding and derivative experiences… then I agree whole hardily that each coding event yields knowledge to use a building blocks to be an excellent developer. The blocks are built in the same way for those open minded individuals that seek more than just technical experiences. In life it is very natural to possess passion for what you do and the products you create. Did you create something 3 months, 6 months or even a few days prior that you could do better? Yes. I have been there so many times where the blocks of knowledge gathered offer new perspective on how to refactor/reshape a design used to make it more efficient, easier to read and easier to maintain over time. Unfortunately considering business constraints it is critical our development team build systems that survive long periods of time. To be successful as a team is absolutely mission critical to build with long range vision of how can these products survive the test of time. A business does not have the appetite to throw away money (or at least in my experience has very little interest to do so) on wild goose chase ventures or suffer the consequences, going out of business I am passionate about what I do every day. This drives me and my team but don’t confuse passion for blindness. Of course, business constraints exist where I can’t “scrap it and start from scratch”. We support hundreds of customers that depend on these systems to operate their businesses. However, when we experience a situation where we have to introduce a new module, feature or new system altogether it is critical to step back and think, “this is how I did it before but how can I do it today considering new technology, delivery networks and best practices known in the technical community.” We exercise this approach time and time again as we move our solution to a centralized offering in “the cloud” (buzz word I am really getting tired of… side note). The incremental advancement is a bit of a way of life when an application has survived such a long period and will continue to do so over an even longer period. Taking things personal and being blind to new ideas, design patterns and best practices is misplaced in the development industry but being forward looking and passionate is a quality I seek from individuals to expand my team now and in the future.<br /><br />Yours truly, the passionate developer<br />Anonymousnoreply@blogger.com