To make something better is a great feeling. But is 'better' equivalent to 'as good as possible'? Is it 'the best'?
- how would Jon Skeet (or any other authority) do it?
- is it SOLID enough?
- wouldn't code reflect domain model better if I ...
- the solution created last week seems a bit 'dirty' to me, there has to be better way to do it, even
What I'm going to write below is nothing new for anyone who've done fully fledged distributed systems development. BEAM veterans, hAkkers, Rafters, ZooKeeper consensus pursuers or Paxos tribe would probably call me Cpt. Obvious, but surprisingly (or not) majority of .NET people I meet & talk to still live the myth of ...
Developers worship Defensive Programming. Once they realize (some never do)
Jurgen Appelo did it again - he has kinda shot 140 char Twitter cannon in a way that has nail'd the point completely:
Most likely he's intentions was just to stop people babbling around and actually do something instead, but I'd
There are important thinking barriers to cross (break?) in a professional career of a software engineer. They are marked with some sort of epiphanies, for instance:
- "WTF?! I have to work with this legacy code, instead of creating something completely new?"
- "WTF?! How can I troubleshoot that if I don't have access to production DB?"
- "WTF?! I've just wanted to swap lib A for
Let's start with some bold statements:
- Team that did shitty waterfall work will most likely do a shitty agile work too (you can freely substitute the word 'agile' with Lean Six Sigma, CMMI3+, XP or whatever)
- Nice tools can make a noticeable impact (by improving morale, increasing dev agility, etc.), but even the best tool won't solve the actual, root problem you have with
The prose of life
Test automation ain't trivial & there are several reasons for that, including:
- need for scalable structure (hierarchy, naming, etc.)
- dealing with dependencies (coupling)
- insufficient speed of execution affecting dev agility
- shared resources impairing isolation
- inertia of data (incl. configuration, parameterization, etc.)
But there are two even bigger issues I'd like to mention (& elaborate more about one of them):
Among all the interesting sessions at Lambda Days there was one titled "The Tools That Shape Us" by Andrea Magnorsky. I liked the topic & the way it was presented, but in this blog post I'm gonna focus on just one (but very interesting) statement the speaker has formulated during this presentation. I don't remember the exact words, but I think that the meaning
All of those cases below are not made up. I’ve met with those cases -> sometimes as ideas, sometimes they were even used in practice. But they all have one common feature - they should be avoided at all cost. To simplify things, I’ve used Git Flow naming convention, as it’s pretty versatile (http://nvie.com/posts/