Register
View RSS Feed

//no comment

Programming is Personal

Rate this Entry
This is something I've been thinking about ever since I started working on TSM (which has had more users interacting directly with me than anything else I've worked on so far in my life), but has become increasingly relevant recently with the release of TSM 2.0. For me, the process of programming (and really engineering in general - but I'm focusing on programming) boils down to three things:

1) Understanding
This part just takes practice and intuition to do well. The problem is rarely clearly defined and is often open to interpretation. In reality, for 99% of projects, you will never (and can never) fully understand the problem.

2) Design
This is really where the engineering part of software engineering comes in. The common definition for engineering is the process of solving problems. That definition is accurate, but definitely doesn't tell the whole story. Engineering involves creativity, outside-the-box thinking, and a systematic process of weeding out bad ideas and highlighting the good ones. This is where it becomes personal. Every engineer thinks their solution is the best possible solution to solve the problem.

3) Implementation
Implementation is easy. This is mainly just the application of the programmer's technical abilities. Not to say that this part is boring, but pending any unforeseen challenges (of which there are often many), pretty straightforward.

For most projects with an active user-base, the first part is the hardest. Users are never satisfied. If you give them a device that can teleport them from New York to London in 10 seconds, they'll ask why can't you do it in 5? Now, I'm not saying this as a bad thing; having consumers who want better things is the entire basis of the free market economy. However, this also leads to the notion of software never being done, and this is precisely with understanding the problem is an impossible task. It's a constantly moving target.

At the same time, software is an expressive medium. For most programmers, myself included, the software we write is a expression of our thought process and creativity. This is especially true with game developers (which I am not). I'm not sure how many people have seen Indie Game: The Movie, but it's a documentary about various makers of indie games (read: games made by individuals rather than big companies). While TSM is very small compared to the games portrayed in the movie, I could definitely relate to some of the emotions expressed by the game developers about their games and the community. A lot of this emotion comes from the inherit self-criticism among programmers. The mindset is that their software should work flawlessly, and when it doesn't, it's very easy to view it as a personal failure. This is why programming is so personal.

Now, let's bring this back to TSM. Obviously with the release of TSM 2.0, there has been a flood of comments from the community, both positive and negative. Let me be clear that I generally (at least try to) view bug reports and constructive criticism as positive. It means somebody cared enough to let me know that there was something that didn't work, or that they would like to see improved. The negative stuff is where all the personal attacks, angry rants, and otherwise unhelpful feedback is contained. I've gotten my fair share of this, but have usually found that a positive response on my part will turn the entire conversation around fairly quickly and effectively. Otherwise, I just ignore the negative comments. Honestly, if somebody can't be bothered to help me make the addon better for them, why would I go out of my way to do so?

The positive side of things is what makes the whole process truly fun. This comes in many forms, from thorough bug reports to thought-out feature suggestions to from happy users extending their appreciation for the software. In order to end this post on a high-note, I'd like to share just a few (sharing all of them would take all night) that fall in that third category that I've received over the past few days.



Thanks to everybody who gave constructive feedback so far on 2.0, and I hope you'll continue to do so in the future. We've tried to make it as easy as possible with our new feature suggestion website, and it seems to be working out even better than I expected which is very exciting. In closing, I'll say that I love working on TSM, don't have any plans to stop, and am working hard to make TSM 2.0 even better than it already is as I write this article. It's all about building a better mousetrap.
Categories
Uncategorized

Comments

  1. theatermusic87's Avatar
    Out of curiosity as a programmer, why have you rebuilt from the ground up TSM as many times as you have? I know what it does hasn't changed that drastically from the beta version to 1.x to 2.x, however the WAY in which it does what it does seems to have changed pretty drastically. Obviously you're trying to better the addon, streamline your code etc, however are the drastic changes coming about due to a lack of ability to do what you wanted with what you had coded originally, or do they just simply stem from a better understanding of how to code what you want; or is it even something as simple as blizzard changing the framework of code that you can work with?
  2. Sapu94's Avatar
    Quote Originally Posted by theatermusic87
    Out of curiosity as a programmer, why have you rebuilt from the ground up TSM as many times as you have? I know what it does hasn't changed that drastically from the beta version to 1.x to 2.x, however the WAY in which it does what it does seems to have changed pretty drastically. Obviously you're trying to better the addon, streamline your code etc, however are the drastic changes coming about due to a lack of ability to do what you wanted with what you had coded originally, or do they just simply stem from a better understanding of how to code what you want; or is it even something as simple as blizzard changing the framework of code that you can work with?
    Ugh, accidentally closed the page after writing my reply, so here goes again...

    This is an excellent question. The answer is that I've gotten much better at coding and more familiar with the features and limitations of lua / WoW which has enabled tackling more difficult problems.

    Here's an example. In 2.0, we use a ton of scrolling tables from displaying all your sales in TSM_Accounting, to the TSM_Destroying popup, to the Auctioning post/cancel/reset log. Back when TSM 0.x was around, this would not have been possible. The few scrolling tables we did have were all manually coded, which was a massively complex undertaking. In 1.x, we starting using libst, which made the process of scrolling tables MUCH more manageable and made modules like TSM_Accounting, which uses a ton of scrolling tables, possible. For 2.0, I essentially made my own version of libst that is now part of TSM. This made the creation and management of scrolling tables easier still, and as a result we now use scrolling tables abundantly throughout all the modules.

    Throughout the history of TSM, we've been constantly adding new tools that we can use to tackle some of the more challenging use-cases and improve areas of the addon that aren't working as well as we'd like. The big change in 1.0 was to move from a window hanging off the side of the AH to our own AH tab. In 2.0, we centralized groups and better integrated and standardized all the modules.

    I think TSM is reaching the leveling off point with 2.0. I feel 2.0 more than any other release has given TSM a solid system to build on. In 0.x, we were mainly just maintaining the functionality of its predecessors (Auction Profit Master / Scroll Master) while experimenting with new areas (ie Shopping). In 1.x, we were polishing the countless number of rough spots in the design and UX of 1.x. In 2.0, we tried (and imo succeeded) to look at every aspect of the box that TSM lives in (gold making), and see how TSM could be as effective as possible in each area. We now have a great platform to build upon for TSM, which is something I never could have said before. Compared to the release of 1.0 where I already had a TODO list for 2.0, now with the release of 2.0, I don't foresee a 3.0, and my TODO list is for 2.1 instead. I've always had lofty visions about how TSM would turn out in "the future" and I honestly think 2.0 encompasses all of them and more. The prevoius versions were important stepping stones to build up all the tools TSM 2.0 relies on (as I mentioned) and to get a better idea of what the users of TSM use/want TSM to do.
  3. Kathroman's Avatar
    Yeah, I usually take a similar approach.

    With every new project I tackle, either at work or at home, I TRY to do at least 1 thing "differently", forcing me to learn something new. Often, this leads to a more effective way of handling past problems, and I'll then go back and rewrite them. Otherwise, once i've come full-circle, I'll have several options to choose from if I'm now at a "rebuild from scratch" sort of place.

    Essentially, you can't know or have access to everything from the get-go, so you work with what you've got and then learn by trying out new things. Then, you go back and refactor your code.

    Rinse, repeat
  4. Wenchie's Avatar
    I have a terrible head for math as well as being rather clueless with coding. I am certain I could improve upon both if the will to do so was there, but a lack of natural aptitude for numbers left me a little lacking in enthusiasm.

    Despite all this, I still love the things you are doing with the new TSM version. Where some people would shy away and panic because it was different from what they were used to, I see the potential there if I can overcome the challenge by widening my knowledge even just a little. So for now I stick to simple price formulae and group arrangements while my head is working on trying to visualise what I want my end result to be rather than by trying to make TSM fit what I am used to.

    I have no end of admiration for people that are prepared to undertake works like this for public use. While math and coding are alien languages to me, I spend a lot of time making things in my real life (tailoring, needlework, papercrafts etc). I find myself very personally attached to my creations and its like placing a part of myself into the item I create. When that item is for a friend or family member it isn't too hard to part with the item. Creating things to sell to others or for charity works are painful for me though. Each new person looking at the item I have made makes a judgement. Its always very clearly on their faces as they see an item to purchase and a face selling it. They don't consider the hours of work and the personal bit of joy you can't help but feel when you look at the thing that didn't exist before you started and is now almost a part of you, looking or doing exactly how you imagined. I've always imagined it must feel the same for writing an addon or creating a video game. Here you need to please so many people and whilst you rarely see their judging glances at your creation, you see it written in streams of angry complaints that may well have been intended to just express someone's frustration but end up just sounding like petty criticism with no constructive side to it at all.

    I know my own feedback tends to be rather unhelpful at times, which is mostly because I always assume I've done something wrong in trying to make it work rather than that it could be a bug, but I'd hope that at least I never manage to make you feel like the hard work of you and your team aren't appreciated.
  5. Halfgnight's Avatar
    First of all, thanks for the awesome addon. I just recently started playing WoW again after a nearly 2 year hiatus, and wanted to get back into making gold. Hadn't used anything other than Auctioneer in the past, and TSM actually looked intimidating to me at first glance. Glad I gave it a shot, as it's saving me loads of time in posting and organization. I haven't even begun to dig into the many other features offered, but look forward to using them as they become necessary for my gold making.

    I'm a software engineer myself, and I completely agree that programming is personal. Everything I do at work is a reflection of MY skill and personality. If my software fails, I fail. And now I'm dabbling in app programming for a personal venture into the mobile world. I know very well the journey ahead will be rough with all kinds of bugs and feedback from users. I know personally you've responded to at least a couple of my threads, and I wanted to thank you for being so attentive to your users. That's not always easy for a programmer when just ignoring an issue because you can't recreate it is easier.
  6. calianna's Avatar
    This is a little slow on the draw given that you wrote this over a month ago, but this is a great description of the development process. The thing that new developers (or people outside development) don't realize is how important the first two things are to the overall process. Failing to understand the problem dooms your project before it even starts. If what you build doesn't solve the right problem, it's useless (unless you're extremely lucky and inadvertently solved a better, more important problem). After you truly understand the problem (or at least sorta, kinda, mostly get it), design is critical. If you design it incorrectly, life can become incredibly difficult for you and, worse, your users. You have to consider the various use cases and determine what the consequences are for not hitting them. For example, you're expecting people to enter, at most, 5 items into a particular list. What happens if they do 10? 50? 1000?

    As you said, if you nail the first two, implementation is generally pretty straight-forward. This is precisely why junior developers usually only do implementation. Senior devs and/or experienced project managers do the first two. Learning to understand your customers takes practice and good communication. Good design takes practice and experience. We learn from our failures. It often takes a fair number of failures (or at least serious challenges) in our implementations to teach us how to be better at the first two.

    Great stuff!