by Bozho | Sep 7, 2015 | Aggregated, Opinions
What is a software engineer? And what is a senior software engineer? Many companies define a “senior software engineer” as a person who has spent more then 6 years as a programmer. And that’s not always correct. The other day I was asked whether I recommend becoming a “generalist” or a “specialist”. Whether one should stay focused on one particular technology and become really proficient with it, or do a little bit of everything. I once wrote that if you do a little bit of everything, you become no expert at all. And while I still partially hold that view, it needs to be elaborated. The software engineer mindset never results in narrow specialists. But it doesn’t mean you don’t “drill” into a particular technology. In fact, you drill into many particular technologies/frameworks/levels of abstractions. You become proficient with them, then you move on to the next one. Probably with side projects, probably as transitioning from one job to another, where something unfamiliar is used alongside the known bits. Over time, you gather enough experience that each new technology is familiar and you get get into it pretty quickly. On the other hand, staying focused on one particular technology for a long time doesn’t let you see the full spectrum of possible solutions to a problem. So no, doing mostly jQuery/Rails/Spring/Android/… for 15 years doesn’t make you a “senior software engineer”. The software engineer mindset is about solving the problem. The more senior you are, the faster you are in finding simpler solutions. The more technologies you are familiar with, the more non-localized solutions you are able to produce...
by Bozho | Aug 22, 2015 | Aggregated, Opinions
The Twelve-Factor App is a recent methodology (and/or a manifesto) for writing web applications that hopefully is getting quite popular. Although I don’t agree 100% with the recommendations, I ‘ll quickly go through all 12 factors and discuss them in the light of the Java ecosystem, mentioning the absolute “musts” and the points where I disagree. For more, visit the 12factor.net site. Codebase – one codebase, multiple deploys. This means you must not have various codebase for various versions. Branches is okay, different repos are not. I’d even go further and not recommend Subversion. Not because it’s not fine, but because git and mercurial do the same and much more. You can use git/mercurial the way you use SVN, but not the other way around. And tools for DVCS (e.g. SourceTree) are already quite good Dependencies – obviously, you must put as many dependencies in your manifests (e.g. pom.xml) as possible. The manifesto advices against relying on pre-installed software, for example ImageMagick or Pandoc, but I wouldn’t be that strict. If your deployments are automated and you guarantee the presence of a given tool, you shouldn’t spend days trying to wrap it in a library of your working language. If it’s as easy as putting an exetuable script in a jar file and then extracting it, that’s fine. But if it requires installation, and you really need it (ImageMagick is a good example indeed), I don’t think it’s wrong to expect it to be installed. Just check on startup if it’s present and fail fast if it’s not. Config – the most important rule here is – never commit...
by Bozho | Aug 13, 2015 | Aggregated, Opinions
Two months ago I took the job of adviser to the cabinet of the deputy prime minister of my country (the Republic of Bulgaria, an EU member). And I’d like to share my perspective of a technical person, as well as some of my day-to-day activities which might be of interest. How does a software engineer get to such a position in the first place? Some people from NGO that I used to be part of (including myself) communicated with the interim government our open source campaign and also built the OpenData portal of Bulgaria (based on CKAN). We continued the communication with the newly elected government and helped with opendata-related stuff, so several months later we got a proposal for a part-time advisory position. And I took it, reducing my software engineer job to four hours. I don’t have to mention that hiring a 27-year old software engineer isn’t something a typical government would do, so that’s progress already. What do I see? Slow waterfall processes, low-quality software, abandonware. Millions spent on hardware and software licenses which are then underutilized (to say the least). I knew that before, hence the push for open source and more agile processes. Basically, the common perception of the regular citizen is that millions have been spent on the so called “e-government” and there is nothing coming out of it. And that’s mostly correct. To be honest, I cannot yet tell why exactly. Is it the processes, is it the lack of technical expertise on the side of the civil service, is it the businesses’ inability to provide quality software, or is it...
by Bozho | Aug 2, 2015 | Aggregated, Developer tips
Event (or message) driven systems have some benefits. I’ve already discussed why I think they are overused. It has two flavors, which you can read about in this architectural patterns books. But none of these is what I’m going to write about. I’m going to right (very briefly) about “dependencies” and “coupling”. It may seem that when we eliminate the compile-time dependencies, we eliminate coupling between components. For example: class CustomerActions { void purchaseItem(int itemId) { //... purchaseService.makePurchase(item, userId); } vs class CustomerActions { void purchaseItem(int itemId) { //... queue.sendMessage(new PurchaseItemMessage(item, userId)); } It looks as though your CustomerActions class no longer depends on a PurchaseService. It doesn’t care who will process the PurchaseItem message. There will certainly be some PurchaseService out there that will handle the message, but the former class is not tied to it at compile time. Which may look like a good example of “loose coupling”. But it isn’t. First, the two classes may be loosely coupled in the first place. The fact that one interacts with the other doesn’t mean they are coupled – they are free to change independently, as long as the PurchaseService maintains the contract of its makePurchase method Second, having eliminated the compile-time dependencies doesn’t mean we have eliminated logical dependencies. The event is sent, we need something to receive and process it. In many cases that’s a single target class, within the same VM/deployment. And the wikipedia article defines a way to measure coupling in terms of the data. Is it different in the two approaches above? No – in the first instance we will have to change the...
by Bozho | Jul 25, 2015 | Aggregated, Opinions
Governments order software for their allegedly very specific needs. And the EU government (The European Commission) orders “visionary” software that will supposedly one day be used by many member states that will be able to communicate with each other. Unfortunately, a lot of that software is abandonware. It gets built, the large public doesn’t see the results, and it dies. A while a go I listed a couple of abandoned projects of the EC. Some of them, I guess, are really research projects and their results may be important for further development. But I couldn’t find the results. All there is are expired domains and possibly lengthy documents. But 100-page documents about software are not software. I haven’t seen any piece of code whatsoever. The only repo that I found is that of OntoGov, but all there is there are zip files with “bin” in their name. Even though unused, the software maybe isn’t lost (although the agency behind some of the projects doesn’t exist anymore), and may be utilized by new projects or even businesses. But it’s just not accessible to the general public. It’s probably hidden in a desk, in a dark basement, with a leopard warning on the door (as in the Hithchiker’s Guide to the Galaxy). But the problem is not only on EU level. It is on national level as well. Since June I’m an adviser to the deputy prime minister of Bulgaria (which I’ll write about another time), and from the inside it’s apparent that software has been built over the years and then forgotten. I’m pretty sure this is true in most...
Recent Comments