a collection of lengthy notes on how I am usually coward to do what is wrong and how I am sometimes brave to do what is right. Bits of management and self management, .NET programming, Clojure parenthesis and lots of design mistakes are the things one will find here.

воскресенье, 27 октября 2013 г.

I remember
when, years ago, I was at elementary school I got an important advice from my
grandmother. Once, checking my homework she noted that I should pay more
attention and care to it, despite
the illusion that doing it faster saves me time. The problem was that
I didn’t want to do homework – it bored me – what I wanted was playing video
games, taking a walk or watching some Discovery channel movies about science
and hi-tech. With homework I pursued the sole purpose – to get rid of
stupid exercises in arithmetic and Russian as fast as possible and get to
worthy things. Obviously, this impacted the quality, which was
difficult not to notice for my granny and thus she tried to help and motivate
me to do better. She used quite a powerful argument saying that everything
that’s not done right will have to be redone later. So being more careful and
focused from the beginning I will be able to avoid returning and save a lot of
time for great things even though this might not look this way at the first glance. I did grasped
the idea and, although sometimes I failed to focus on boring stuff giving way
to mistakes, I kept in mind the notion that one should take care to do
everything the right way so that they don’t have to come back to it long after.

Still, now
it seems to me that I got the advice wrong and took it too far, which produced
a very bad side effect on the way I work. What I mean is that when trying to
create something that is important and interesting to me I become obsessed with
the quality of the thing long before it even begins to emerge. This way I
quickly find myself in exhaustive search for the right ways to implement every
tiny piece of what I am trying to accomplish and during its course I
usually can’t allow myself to sit down and build something little and
potentially dirty, because I remember this is a waste of my time. One may
think that is great and helps me create nice and wonderful stuff, however the
reality is harsher. This chase for perfection giving birth to the fear of dirt
actually raises a stone wall between me and long waited moment of achieving my
goals.

The reason
for this is that creating means learning. Learning, in turn, can’t take place
without building dirty things and making them better – as far as I know, there
isn’t such a thing like a direct way to mastering something without making a
stupid mistake or two first. It took me long to accustom myself with this idea,
see how it hampers my own work and learn to spend less time on weighing
infinite number of alternatives, throwing them away and finding and weighing
some more, again and again. I have many times faced this problem when writing
posts for the blog, but eventually I have developed a habit of quickly hacking a couple
of dirty sketches without concerns of the language and other aspects of
quality. Doing these I literally push myself to leave white spaces and
ignore the fact that some of my phrases feel Hulkish at best – this way I can
proceed knowing that later, when I see the full picture clearly, I will return
and make the ugly parts polished and shiny. Such an approach saves me a lot of
time, which would otherwise be wasted on searching for words that are yet to
come and expressing the ideas, which I realize only partially. In fact, there is
nothing bad or inefficient in producing a thing that lacks
elegance or even correctness on some stages of the process.
Moreover, doing so doesn’t hurt the quality of the final product at all, as long as one remembers to return this debt later.

Fellow
coders might have guessed that I learnt this approach through programming.
Kent Beck’s ‘Test-Driven Development: By Example’ book was the first thing to
introduce me to the idea condensed in the words "first make it work, then refactor". While Kent deals
mostly with the low level of code in the context of solving a specific bit of a
problem, the advice is also applicable to most other levels and aspects of the software development process. I find it particularly helpful when working with
new technologies – languages, frameworks, libraries and whatever else: in many
cases spending a lot of time on trying to figure out the abstract right ways to use the tools turns out to be a major waste of resources of any kind. On the other side, actually
taking what you have and building something, maybe so ugly and stupid that
even stackoverflow won’t bear its presence – but working, provides one with better understanding of both means and goals. Honestly speaking, I
rarely realize what I want from a particular tool until I actually try to
use it some way, thus the chase for perfection ‘from start to end’, although
may produce something nice, most likely won’t lead me to what I wanted.
Moreover, there usually exists a chance that I will fail to create anything
meaningful at all.

Perfection
requires major investments and a firm basement, which is to be built from
something common and dirty. In the end, it is quite difficult to claim a
cathedral a piece of art while it is being constructed from stone, steel, cement
or clay, but no one will remember what its naked walls and empty windows looked
like once it is finished. I believe that years ago my granny didn’t want to
make me do my homework perfectly correct right away. What she meant was that I
should start whichever way I like but not stop until the thing looks beautiful.

понедельник, 21 октября 2013 г.

Recently I
have faced the problem with Intellisense performance in Visual Studio 2012 for
C++ , caused by Precompiled Headers feature being disabled. After eye-parsing
some pages on the web including MSDN itself, MSDN blogs, stackoverflow and some
other, I have managed to make the thing work fast enough, so that it doesn’t
prevent me from coding. Still I find both the issue as well as the
solution to it to be pretty undocumented and will thus explain my findings here in the
form of a walkthrough.

вторник, 8 октября 2013 г.

These days
I am working slowly on a Windows Phone application. Making my first steps in
this direction turned out to be quite frustrating, although this is a topic for
another post. As a disciplined developer (ha!) I started the project with unit tests
and while writing these I noticed that there is a thing that I do automatically
now. Including a kind of factory method into each and every test class which I
write has become a habit for me, saving a lot of time and effort.

About

I work as a team-lead at Acumatica, the Cloud ERP. Besides, I hack code on my own for the sake of learning, fun and whatever else that programming can bring. To reflect on these activities and structure my thoughts and ideas better I also maintain a little blog.