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
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
Jurgen Appelo did it again - he has kinda shot 140 char Twitter cannon in a way that has nail'd the point completely: You're a Thought Leader? Who cares?! Better aim to become an Action Leader.— Jurgen Appelo (@jurgenappelo) June 9, 2015 Kaboom. Most likely he's intentions
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
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.
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
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
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