[{"data":1,"prerenderedAt":214},["ShallowReactive",2],{"i-lucide:menu":3,"i-lucide:arrow-up-right":8,"i-lucide:moon":10,"i-lucide:sun":12,"i-lucide:rss":14,"i-simple-icons:github":16,"i-simple-icons:linkedin":18,"post-\u002F2011\u002Fbe-a-developer-not-a-programmer":21,"surround-\u002F2011\u002Fbe-a-developer-not-a-programmer":201,"i-lucide:arrow-left":210,"i-lucide:arrow-right":212},{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":7},0,24,false,"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M4 5h16M4 12h16M4 19h16\"\u002F>",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":9},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M7 7h10v10M7 17L17 7\"\u002F>",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":11},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M20.985 12.486a9 9 0 1 1-9.473-9.472c.405-.022.617.46.402.803a6 6 0 0 0 8.268 8.268c.344-.215.825-.004.803.401\"\u002F>",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":13},"\u003Cg fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\">\u003Ccircle cx=\"12\" cy=\"12\" r=\"4\"\u002F>\u003Cpath d=\"M12 2v2m0 16v2M4.93 4.93l1.41 1.41m11.32 11.32l1.41 1.41M2 12h2m16 0h2M6.34 17.66l-1.41 1.41M19.07 4.93l-1.41 1.41\"\u002F>\u003C\u002Fg>",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":15},"\u003Cg fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\">\u003Cpath d=\"M4 11a9 9 0 0 1 9 9M4 4a16 16 0 0 1 16 16\"\u002F>\u003Ccircle cx=\"5\" cy=\"19\" r=\"1\"\u002F>\u003C\u002Fg>",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":17},"\u003Cpath fill=\"currentColor\" d=\"M12 .297c-6.63 0-12 5.373-12 12c0 5.303 3.438 9.8 8.205 11.385c.6.113.82-.258.82-.577c0-.285-.01-1.04-.015-2.04c-3.338.724-4.042-1.61-4.042-1.61C4.422 18.07 3.633 17.7 3.633 17.7c-1.087-.744.084-.729.084-.729c1.205.084 1.838 1.236 1.838 1.236c1.07 1.835 2.809 1.305 3.495.998c.108-.776.417-1.305.76-1.605c-2.665-.3-5.466-1.332-5.466-5.93c0-1.31.465-2.38 1.235-3.22c-.135-.303-.54-1.523.105-3.176c0 0 1.005-.322 3.3 1.23c.96-.267 1.98-.399 3-.405c1.02.006 2.04.138 3 .405c2.28-1.552 3.285-1.23 3.285-1.23c.645 1.653.24 2.873.12 3.176c.765.84 1.23 1.91 1.23 3.22c0 4.61-2.805 5.625-5.475 5.92c.42.36.81 1.096.81 2.22c0 1.606-.015 2.896-.015 3.286c0 .315.21.69.825.57C20.565 22.092 24 17.592 24 12.297c0-6.627-5.373-12-12-12\"\u002F>",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":19,"hidden":20},"\u003Cpath fill=\"currentColor\" d=\"M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037c-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85c3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.06 2.06 0 0 1-2.063-2.065a2.064 2.064 0 1 1 2.063 2.065m1.782 13.019H3.555V9h3.564zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0z\"\u002F>",true,{"id":22,"title":23,"body":24,"category":179,"comments":180,"date":181,"description":182,"excerpt":180,"extension":183,"image":180,"meta":184,"navigation":20,"path":185,"readingTime":186,"seo":187,"stem":188,"subtitle":189,"tags":190,"wordCount":199,"__hash__":200},"posts\u002F2011\u002Fbe-a-developer-not-a-programmer.md","Opinions: Be a Developer, Not a Programmer",{"type":25,"value":26,"toc":166},"minimark",[27,39,44,47,50,53,56,59,67,70,73,76,79,82,85,88,91,94,97,100,109,112,121,124,127,136,139,142,145,148,151,154,157,160,163],[28,29,30,31,38],"p",{},"The following is a transcript of a debate between me an a friend of mine - ",[32,33,37],"a",{"href":34,"rel":35},"http:\u002F\u002Fwaher.net",[36],"nofollow","Kristo Vaher"," - about different ways of developing software. Published with his permission.",[40,41,43],"h3",{"id":42},"ando-roots","Ando Roots",[28,45,46],{},"Developing PHP is messy on its own...but when you have different views of the words \"elegance\", \"simplicity\" or DRY with your colleague...",[40,48,37],{"id":49},"kristo-vaher",[28,51,52],{},"PHP is very elegant. When you write a wrapper for everything. It's like having PHP wear makeup.",[40,54,43],{"id":55},"ando-roots-1",[28,57,58],{},"I spent a day writing everything in ORM, using built-in modules of the framework, CRUD generation etc... then my co-worker slash project manager told me he'd do it himself and basically dumped most of what I did.",[28,60,61,62,66],{},"Elegant ORM became hand-written SQL, ",[63,64,65],"code",{},"$_POST"," data parsing\u002Ffiltering became a function with gazillion parameters, all passed by hand.",[28,68,69],{},"I'm a bit crossed now.",[28,71,72],{},"I think there\"s going to be a ranting blog post sometime in the future with justifications why my way was better. I'm a perfectionist, but also, we don't live in an era where you have to mysql_real_escape_string() on every row of code any more.",[40,74,37],{"id":75},"kristo-vaher-1",[28,77,78],{},"Your way is better, but you are also dangerously close to becoming an idealist, which can hurt projects. There\"s this thing called \"good enough\" principle. It is more important to deliver a working product than to write perfect code.",[40,80,43],{"id":81},"ando-roots-2",[28,83,84],{},"I'm aware of the danger... but I've also seen how projects that were delivered like that have become so huge, slow, error prone and unmaintainable they need to be replaced.",[40,86,37],{"id":87},"kristo-vaher-2",[28,89,90],{},"The basic idea is really that if you spend less time to deliver, you give more time to get feedback. If you work for a month on a startup project before getting end-user feedback and does really suit the needs to end user, you have wasted a month on developing a prototype that otherwise you could have developed in a week. Even our own Challengo is a good example of that, hack-filled code, but it won the best prototype award.",[28,92,93],{},"In the end of the day you need to seek balance between the two. Best developers are still very fast, because they are dirty sometimes. Being quick and dirty does not mean being less secure or less functional, dirty code can still sustain hurricanes of security attacks. I know it may feel \"bad\", but I can assure you that \"knowing\" how to do things better and compromising to get things done faster is sometimes the better way to go.",[28,95,96],{},"What should be really avoided is writing projects into ditches though, which is usually writing huge chunks of procedural code that is all tightly coupled and to replace one part of the system in refactoring process requires replacing everything else too.",[40,98,43],{"id":99},"ando-roots-3",[28,101,102,103,108],{},"Why the hell can't the world be ",[32,104,107],{"href":105,"rel":106},"http:\u002F\u002Fagilemanifesto.org",[36],"Agile","? In the rainbow-filled fictional universe, clients would review progress \u002F give feedback every day. In reality, twice a week will often suffice.",[28,110,111],{},"Best developers are fast - but if you start reinventing the wheel by writing SQL by hand, writing login by hand, basically not taking advantage of the best frameworks offer in terms of speed, modularity, existing functionality.... Using frameworks properly - and I don't mean writing perfect code, just reusing what's already there like ORM - gives you blazingfast speed comparable to Rails or Django... and you have to learn to use it only once.",[28,113,114,115,120],{},"I abhor messy code that isn't commented or is just plain wrong, but I see the necessity of ignoring the rules sometimes. As you said, ",[32,116,119],{"href":117,"rel":118},"http:\u002F\u002Fgarage48.org",[36],"G48"," is a good example.",[28,122,123],{},"Another thing, if I'm forced to write code that way, my creativity and productivity goes down. You could say the same about writers \u002F designers. If the idea of a book goes against what you believe in, you still manage to write it somehow, but it isn't nearly as good as say, some of the works of J.K. Rowling.",[28,125,126],{},"A good foundation is the basis of everything. Every project should have a solid understanding on what and how they build it. Let the functions be messy inside as long as their signatures and usage is thought out and modular - meaning that if you want to add a new field, you don't have to \"replace everything else too\".",[28,128,129,130,135],{},"This could be a good discussion at the next ",[32,131,134],{"href":132,"rel":133},"http:\u002F\u002Fdevclub.ee",[36],"Devclub",".",[40,137,37],{"id":138},"kristo-vaher-3",[28,140,141],{},"There\"s a difference between software development evangelists (people who preach) and actual developers. The real world of software development is different. Of course Agile methods would be brilliant, but they are extremely slow and are almost impossible to implement in wide array of cases (especially social apps). It's similar with quality assurance, unless you\"re working in a corporation with a Q&A team, you have to test your software yourself.",[28,143,144],{},"Reinventing the wheel is bad (and should not be avoided), but so is always being boxed by framework that claims to do everything and then requires hacks should something need exceptions. This will lead to a situation where framework is used with numerous overwritten classes and methods that will be just as bad in the long run. I've personally always been a library-focused developer, I have dozens of classes and tools, but I don't use an actual framework, because frameworks hold me back too much. I don't like to rewrite classes and methods because that adds to overhead, I want to avoid it as much as possible.",[28,146,147],{},"What I have ended up with is couple of \"project setup\" libraries for API services or MVC solutions and go from there. I can get basic service up and running in no-time and can expand it in any direction without any overhead from what a framework would force. PHP especially is in itself a templating language and loss of speed when developing certain things of a website is quickly made up should something custom need to be implemented. I don't mind faster frameworks, but I prefer not to be dependent on them.",[28,149,150],{},"What most frameworks do is that they simplify tedious tasks when in fact they should simplify complicated tasks - but the latter is not possible without massive overhead on the system. I may lose out in development time up to 50% compared to someone developing the same solution without Framework, but I will end up with a system that can easily be hundred times as fast, if not more.",[28,152,153],{},"The right approach is the middle ground. If you\"re creating a website or something that is very much like a website, then using larger frameworks is very good. But if you\"re writing a web service that simply has a web based frontend, then such frameworks are a hassle and will only hamper the speed of the end result.",[28,155,156],{},"Reality is that if success matters, it is all about being fast and getting feedback as quickly as possible and being able to change things very quickly in whatever direction required. If you\"re not fast, you\"re just not good enough. Things can always be refactored later on (and refactoring cannot be avoided by either methods).",[28,158,159],{},"Creativity of software developers cannot be compared to creativity of writers and designers, it's a separate process. Software serves creative needs, development it's not creative itself, it's just functional.",[28,161,162],{},"I would like to think I am an \"artist\" when writing software, but it's not really art. But if it works well and ends up creating emotions to the end user, then the idea or solution is creative. Code itself and programming is not.",[28,164,165],{},"But yes, it's a good topic of discussion! :)",{"title":167,"searchDepth":168,"depth":168,"links":169},"",2,[170,172,173,174,175,176,177,178],{"id":42,"depth":171,"text":43},3,{"id":49,"depth":171,"text":37},{"id":55,"depth":171,"text":43},{"id":75,"depth":171,"text":37},{"id":81,"depth":171,"text":43},{"id":87,"depth":171,"text":37},{"id":99,"depth":171,"text":43},{"id":138,"depth":171,"text":37},"Software Development",null,"2011-09-06","The following is a transcript of a debate between me an a friend of mine - Kristo Vaher - about different ways of developing software. Published with his permission.","md",{},"\u002F2011\u002Fbe-a-developer-not-a-programmer","about 7 minutes",{"title":23,"description":182},"2011\u002Fbe-a-developer-not-a-programmer","Part I",[191,192,193,194,195,196,197,198],"programming","php","design","framework","development","opinion","ORM","SQL",1260,"rHskYlRY5xCp5SlbxEXosrY0aKMMI2Sx0HDp8qkRZiw",[202,206],{"title":203,"path":204,"stem":205,"children":-1},"Another reason to distrust open WiFi","\u002F2011\u002Fanother-reason-to-distrust-open-wifi","2011\u002Fanother-reason-to-distrust-open-wifi",{"title":207,"path":208,"stem":209,"children":-1},"Notes From James Bach's Lecture on Testing","\u002F2011\u002Fnotes-from-james-bachs-lecture-on-testing","2011\u002Fnotes-from-james-bachs-lecture-on-testing",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":211},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"m12 19l-7-7l7-7m7 7H5\"\u002F>",{"left":4,"top":4,"width":5,"height":5,"rotate":4,"vFlip":6,"hFlip":6,"body":213},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M5 12h14m-7-7l7 7l-7 7\"\u002F>",1790886934276]