10 Jun 2014 @ 6:54 AM 

It is an interesting phenomena to consider, our human ability to turn that which we find extraordinary into something mundane, or even undesirable through repetition.

For example, as far back as I can remember I remember that I would have given anything for a Job that let’s me deal with computers and/or programming all day long. I even promised myself I would never take it for granted.

For the last year that has been a reality- and that reality turned from a dreamy visage that I expected to be forced out of into a harsh reality where it did not exist, to something more like the constant cold feet you would get from not wearing socks during winter. It’s something that we might not notice without reflection but something that I think we all should be vigilant for to prevent stagnation.

I recently noticed that about myself. And it has a implicit duality that makes it both dumb and valid simultaneously. On the one hand, we have a case of comparing what we thought to reality- and what we think something entails seldom fully indicates what that something is in reality. After all even the best job will leave you frazzled and worn out at times.

At first I thought this was a result of it not being a fit. Perhaps, I reasoned, I simply cannot do this. However on further thought I think that is simply a good indication that one is working. It’s possible to both love doing something while at the same time not enjoying it. This also has an interesting mixin (no pun intended) when we look at the overall message of books like “Clean Code”. Many of the common frustrations of Programmers is the result of, well, programming. For example, if we are constantly bumping into some code limitation we built in a library; or we are frequently writing and adapting to new viewers and wrappers and filters and other programs that call other programs who’s syntax is frequently changing and so on and so forth. Just yesterday I (and a few others) spent the entire day trying to figure out a single problem that turned out to be a comparison method that was not transitive- and was used for completely redundant debugging code. I wasn’t able to appreciate the irony of something written to aid debugging causing problems with debugging later at the time but I can do that now.

It is an interesting contrast to compare the sort of solid, well-engineered, modern software you expect to see being used for businesses mission critical software with the software actually being used. As an example, at my previous job we clocked in and out using a touchscreen system. The software was reasonable on the surface but I was able to copy it and decompile it and see the guts and it features innumerable things that I found abhorrent; hard coded passwords and usernames, poor flow control, and all sorts of other oddities that seemed completely out of place for a software suite that had it’s intended level of usage.

Of course that perspective fails to take into account the possibility that the software had to remain compatible in some way with older software; or perhaps at some point it was moved from ISAM to another database until finally being moved to MySQL and accessed from C#. So it has a lot of legacy.

I have yet to finish the book “Clean Code”, or really even get started. But one message I think I found that seemed clear was the idea that software should be rewritten at intervals. This flies in the face of my more conventional understanding where rewriting an application or program is bad, especially considering we have so many examples of the latter. But the reasoning it presents seems quite sound, And certainly seems to fit with my own experience. The fundamental idea is to prevent too much legacy from carrying over from decades previous. For example, if we have a MySQL table called “RESVPOSX”, then we have a very clear smell. And in the long run it is always best to eliminate as many smells as possible. It just makes sense.

The problems appear when airing out the code in such a fashion by refactoring it, renaming things, and moving things around as well as adjusting them start to stack up in terms of man-hours as well as causing even more problems. It can seem almost counter-productive- one day it is agreed that the configuration names need to be standardized, the next you are dealing with the problem of moving the old systems using the non-standard names to the new system without breaking other systems at the same site that are running the old version and not breaking new versions when those old versions run. It’s a endless game of cat and mouse and fundamentally there is no end to it. Any piece of non-trivial code can always be made faster, cleaner, easier to read, or easier to use from other code. The real question is when you draw the line.

As a direct example I’ll take BASeBlock. For the moment we will ignore that I haven’t touched it in ages since that isn’t related to my point. It was effectively a rewrite of a game that was pretty much the same. I learned new things while writing that first one and applied them to BASeBlock; When I wrote BASeBlock I learned even more and applied them to “PreHender” which is a game who’s name had some clever backstory that I don’t remember at all but has at least succeeded in making a name that seems unique. This is important, I think- learning new things about the language and technologies of which you use. It’s even cooler when you get to use those technologies and programs in your work later on- There is something somewhat fulfilling about having Update code I wrote over 5 years ago in my spare time when I was making minimum wage be applied and reconstituted with a dose of liquid refactoring to a real live project used by real live people. At the same time, however, it can also be scary. to take another direct example of this, for this website early on I felt I could use an Updater. Or, rather, the creation of an Updater to meld with the PHP of the site seemed like an interesting challenge. And that is what I did- I created a web-based Update system that I found to be quite powerful. It existed in a few of my programs but to be honest nobody is going to be affected financially if their version of BASeBlock is out of date. There is something- uneasy- about having that code be placed in an environment where it working and working well is of the utmost importance. This I have done and if there is one thing I can say it’s that we have somehow moulded it into something that works great and presents a pretty cool looking sort of “front-end ” first experience of sorts.

My use of the word “we” rather than “I” is important above. If there is one thing that is important to realize is that in any development team there are islands of one. Without the ability to work with others you are going to fall on your face; and without the ability to interact with others without exposing yourself as a social retard you will also experience problems. The worst mistake any developer can make at any point is to ever think they are, for whatever reason, smarter than their co-workers. That is an incredibly stupid and perhaps ironically small-minded approach. I won’t get into that too far except to state that if at any point you think that, you are wrong. wrong wrong wrong. Additionally, it’s worth noting that if you are in such a state of mind where you are thinking such things about your other team members, they are almost certainly thinking the same thing about you. A team where every person thinks they are the smartest will end up being the dumbest- it’s anti-productive and trading in productivity as part of a team for some form of validation of your own hubris is one of the biggest mistakes you can make.

A much better approach seems to be that expressed By Scott Hanselman. Fundamentally, if you just assume you are the dumbest, the worst outcome is you learn. On the flipside, this does mean you can’t just let your team members blame shift everything onto you. One needs to strike a healthy balance, and it is almost certainly difficult depending on the size and makeup of the team in question.
and work towards a common goal- Too often you see development teams and IT teams turn into a game of office politics where individuals blame-shift to other members of their team in order to position themselves in some entirely imaginary “pecking order”; This is counter-productive because it doesn’t establish any form of teamwork, instead of drives wedges between members of the team and creates rivalries.

Another consideration I think is important is to keep your mind at work. Speaking personally the challenges I would face through my work are going to be wholly different in many ways from any I would face from my work on BASeBlock or Prehender, or many of my other projects- Still programming of course, but the problem sets will be entirely different. Where one focuses on legacy compatibility and data integrity, another focuses on what particde timeout and acceleration or alpha falloff makes the coolest explosion. There is something to be said about being able to write an Application or Program without having to care about whether it ever works- This is something that I did back with VB6; I had so many program ideas over time (it’s a shame I lost them) came up with entire MenuStrip-type frameworks that used hooks, wrote custom tab controls, and all sorts of things like that, but at no point did those things need to work- that is part of what might have made it most enjoyable. That is not to suggest that working on programs with goals that need to be met is much different- the difference is simply that the goalposts are more rigid, but they also won’t get smushed under the weight of not caring, because you need to care on a professional level.

Posted By: BC_Programming
Last Edit: 10 Jun 2014 @ 06:55 AM

EmailPermalinkComments Off on Anything can be the norm
Tags: , , ,
Categories: Programming
 14 Oct 2013 @ 12:21 AM 

This is a topic that I find recurring between myself and my non-programmer friends, as well as people providing freedback on some of the Open-Source repositories I contribute to and help maintain. Questions such as “what drives you” or “if you aren’t getting paid, why do you do it?” Sorts of questions.

My normal response is “Why do painters paint?”. The old standby. But I think it’s an interesting question too. The reasons that I like to develop, design, and implement software can be traced to the same things. I Enjoy programming for a multitude of reasons. It’s something I’ve found that I’m good at, and that I can continue to grow better at over time; there is no glass ceiling of skill that I will hit. Something about it makes it far more expressive than it would seem at first glance. There is more than one way to write a program to do a non-trivial task, and with experience and skill you are able to become familiar with both the language in question as well as how you use it; and you can carry over some of this skill and ability into everything you do.

There is something innately fulfilling about looking around and seeing people benefit from software you’ve written, regardless of what it is. Arguably depending on the software there is also responsibility for that software that you implicitly take on regardless of any “Terms of use” that remove such warranty. For example even though you are legally in the clear if a piece of software does something it shouldn’t or causes a problem for a user, you are still bound by the contract of not being a massive douchebag to at least try to help especially in terms of fixing the bug if not helping to recovery any lost time or data that the user lost.

Even in the most boring and otherwise dry Application, there is some consideration to be made for how maintainable the software is going to be. If you go into a large project and just code what you need by the seat of your pants you are just going to make more work for yourself in the long run; so you have to try to get an idea of the larger picture, and then focus on drawing out the details in each area so it flows smoothly; like the charcoal pre-painting step of an accomplished painter, you are able to see if this will work in the overall composition as per the software requirements. Additionally even in the most restrained set of requirements there are choices and decisions to be made by the programmer in terms of the actual make-up of the code and logic- eg, what will be represented by classes and how those classes will interoperate. A common quotation, (though I’ve forgotten the attribution) is, “The definition of Insanity is doing the same thing twice and expecting different results”. I guess you could say the definition of Art is getting two people to do the same thing and getting vastly different results.

This takes me to the almost separate topic of whether Software Development is an “art”. I’d say that it is in many ways- the aforementioned tongue-in-cheek definition being a good example of why this is. But at the same time, how is it “Computer Science” when it’s actually an Art? This is something that baffles onlookers to the subject- some Programmers feel they are artists. Others feel they are academics working in a professional Science.

The answer is simply that they are separate. For example, when you study light and colour and pigments in chemistry and science classes- that is science. It is when you apply that understanding as well as a understanding of how we [i]interpret[/i] colour that it becomes an art; and in terms of painting (or any graphical art) the “art” is more in terms of using the skill with the medium to give a message. When it comes to Programming, we have a bit of a different thing going on; I’d say that for Software Development you actually have to deal with two things- you need to deal with the Compiler/Interpreter/Computer that is compiling and running your code, but you also have to deal with the people who will read your code later on, including yourself. It becomes an “art” to balance the requirements of the program and try to come up with the most elegant, and easy to read Source code to describe an otherwise complex problem.

I imagine this is partly why I find it so fascinating. Another reason is that once I’ve written something well, and moved on- I can always both revisit that project or class to make improvements, or simply touch it up and post it here on my blog (which I’ve done for a few classes) which actually has another interesting sidebar in that those improvements I do make often come as a result of my actually opening that project or class to try to touch it up for a new blog post. In that way I build up a library of small libraries, and classes that I can use for a variety of common tasks, making complex requirements such as high-level automatic support for List View Sorting UI handling almost trivial. I think this sort of “art” helps the end-user because it means for example that the otherwise complex functionality, which now takes a single line to actually implement, basically needs a good reason to not exist. You cannot argue that it would take too much time to add a single line of code to add the implementation, and the class itself being reasonably well-tested is a sort of assurance of how well it will work.

That isn’t to say it’s always fun and games. TO be honest I’m actually a bit disappointed with how little work I’ve done- I mean I do have a good number of projects, but I feel I could have a lot more, and even then those projects I do have suffer from neglect because unfortunately there are only 24 hours in the day and I’ve decided against moving to Venus because I prefer to not have my skin boiled off and corroded by a real-life dutch oven planet, even if that would give me a day that is 100 times longer. And that joke had far too much setup and a delivery that makes me glad I didn’t pay shipping. Anyway- I don’t even remember when I last opened BASeBlock- and even then it was probably to see how I did something to try to adapt it for a work project; I would have to look back even further to see what the last time was that I actually opened it to try to get some work done on it. Another issue I’ve found for those projects recently is that now that I actually do this sort of thing for my actual work I find that- unlike my previous Jobs- At the end of the day I simply don’t want to see Visual Studio anymore. This is actually fine by me- it tells me that what I am doing is mentally engaging and I’m still learning.

This actually makes me understand some of the weird habits I’ve seen from career programmers. I’ve noticed for example that many career programmers that have hobby projects will make their hobby projects in another language from their work, which I’ve never entirely understood. But Now I can see- they want to distance those hobby projects from the work they do to make their living, if only in their own mind. Even using a separate IDE for the same language can sometimes make the difference. For some Java Work Projects I used Netbeans, but for my hobby programming in Java I used Eclipse (And now finally switched them to IntelliJ IDEA). The fact that you are in a different environment is a “cue” to your brain to do stuff your own way, I suppose.

That said, I still hope to eventually get back into developing Prehender. It’s fun to learn new stuff and even deal with OpenGL while still being able to rely on my skills with C#. And it would have the advantage of being a completely different playing field from anything else I do or have done.

Speaking of “Prehender” who’s name’s origin I’ve forgotten, but there was a reason for it- I ought to write a blog post on the gameplay ideas I had for that. It’s not revolutionary but it’s simple enough to be something I feel capable of even with my limited 3-D experience while still being something I think would be a playable and engaging game experience.

Posted By: BC_Programming
Last Edit: 14 Oct 2013 @ 12:21 AM

EmailPermalinkComments Off on Software Development: What makes it fun?
Tags: , , ,
Categories: .NET, C#, Programming

 Last 50 Posts
Change Theme...
  • Users » 47469
  • Posts/Pages » 391
  • Comments » 105


    No Child Pages.

Windows optimization tips

    No Child Pages.

Soft. Picks

    No Child Pages.

VS Fixes

    No Child Pages.

PC Build 1: “FASTLORD”

    No Child Pages.