RSS

Why work for a software company?

Entry 37

When I was looking for a new job recently, I had a strong resolution, that I’m going to work for a company that is doing software. Not telecommunication equipment that requires software. Not financial products that require software. Not trucks that require software. I wanted a company, that does the damn software for a living. And I will tell you why.

Case one: Technology Corporation

800px-base_transceiver_stationIt’s not bad, could be worse. Companies that focus on technology usually have some kind of understanding for engineers. Usually. There is the corporate aspect though with all the bureaucratic nonsense. The bigger the company is the more problematic the aspect of scale becomes. Some people are allergic to presence of nonsense, and probability dictates, that with scale, at some point you will encounter the nonsense and might get frustrated.

The urban legend says, there is a quarter million Euro device rusting on the shelf in a lab. It’s needed, but no one knows how to turn it on. The one competent guy who knew left the company because he was unable to get a hundred Euro rise. We can’t rehire him for a year because of policy. Meanwhile new people straight from university are paid more than that  competent guy who left, because we need more people and there is no people, so we have to attract people somehow.

Case two: Single Product

ultimate-guide-to-your-product-launchA small company with single software product seems to be good place to be in. It’s likely that you can avoid a lot of problems connected with working with random people from random countries you will never see in person. You can storm into CTO office and ask for few hundred bucks for an innovative idea you want to introduce, and there is a good chance that you will get it without bullshit paperwork. You happened to drink beer with most people in the company and that’s always helpful.

The problem might be the product itself though. If the product is old enough to get its own driver license or buy alcohol, and it hasn’t been taken care of really carefully, it might be difficult to work with and the development can slow down to a crawl. And if you are defeated by the difficulties at some point, there is nowhere to run. It’s the single product company.

Case three: Investment Bank

Perkins.pngOh boy. I’m not a good person to be objective about banks. They pay a lot I can’t deny. But aside from that it was difficult for me. First of all, I’m not the dress code guy. I prefer to wear geeky t-shirts, shorts and sandals to work, period. Second: freedom and autonomy. You can’t do anything in there. Your computer is a virtual machine somewhere far away, you can’t install stuff you need, you can’t access stuff you need. I remember wasting half a day to get FireBug plugin for my browser. It was not in official repository, I couldn’t get them do place it there, I couldn’t send it via email, download site was blocked. Finally, I found out they didn’t block site with older version, like a week or so.

The biggest problem is that people who understand you can’t do anything and people who are able to do something will likely not understand you. I had a lengthy email conversation with a guy in a suit, who apparently understood only Excel, somewhere three levels of hierarchy above me. I was trying to convince him that serious developers need second display otherwise they are unproductive and basically unhappy. It was explained to me, that we work in “smart” office which meant everyone has thin client with single display and virtual machine no matter if you are developer or secretary. Single display. Everyone. Nothing can be done. Equality.

Case four: Trucks Factory

afghanistan-in-the-1950s-and-60s-15Truck factory has an IT department and software development because it has to. Everyone does at some point. They might be building marvelous trucks, but software is not their focus and it will kick you in the ass at some point if you are software developer. People with real power and vision were thinking about trucks, not software, so they didn’t care about software very much.

Of course, it depends on the setting, but in my case I was literally the part of a factory. There was a huge complex where they build trucks, buses, excavators. And software. When I asked why there is no damn tea in the kitchen, I was told that labor union from the factory said that either there is tea in the factory too or no one gets to have tea. Guess what happened. Also, I had to routinely show inside of my backpack when I was leaving premises. Because I could have been walking with some expensive part of a truck, apparently a common practice among factory workers. Life is difficult outside of IT.

Case five: Software House

4662386Finally, the company that does software as its main business. People with real power and vision think about software. And there is a good chance that they were software developers at some point, so they will understand your problems.

Ideally, software house has a lot of projects for different clients. They get in, do the software and get out. And learn along the way. Of course you may still end up in some shitty legacy system, but at least there is a chance to escape to another project. And there is a common understanding on how things should be done in software development, so if you want to make the situation better at your client office, you will likely get support from your software house.

What now?

That’s my story. These cases are generalizations to some extent of course. You might end up in non-corporate corporation. Or single product company with a great product to work with. Or unusually opened and relaxed bank. Or factory that doesn’t treat software developers as factory workers. Or a crappy software house.  But be where you are consciously. I often see people who work in their first job for ten years and just assume that’s how things should be done. I’m not saying you can’t be happy like that. But maybe, out there, outside of your comfort zone you cling to so much, there is a better, fascinating place waiting to be found. Don’t be afraid. The world belongs to the brave.

Besides, what can happen? The tiger suddenly jumps from behind the bush and eats you?

p.s. If you like violin and electricity, I have two nice music videos featuring breaking out of comfort zone and taking the leap, enjoy!

work-for-software-company

 
3 Comments

Posted by on September 29, 2016 in Misc, Recruitment

 

Tags: ,

Good commit message

Entry 36

Last time we talked about version control, so let’s elaborate a bit on that. One of the aspects of using version control is the possibility of commenting on changes you do in the code. Actually, it shouldn’t be only the possibility, it should be a necessity.

The Template

Git documentation provides a standard template and guidelines for commit message, let’s have a look.

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72 characters or so.  In some contexts, the first line is treated as the subject of an email and the rest of the text as the body.  The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run thetwo together.

Write your commit message in the imperative: “Fix bug” and not “Fixed bug” or “Fixes bug.”  This convention matches up with commit messages generated by commands like git merge and git revert.

Further paragraphs come after blank lines.

– Bullet points are okay, too

– Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here

The News

The most important question to be answered by the commit message, is what happened. Think of list of commit headers as a news feed about your project or headlines in the newspaper.  You want to know what happened first. Then, usually, why this happened and maybe some more details about it. But not too much. Remember one of Agile Manifesto ideas: Working software over comprehensive documentation.

You are talking about changes, so use active voice. Choose a tense you want to use and stick to it, so the story of your project is coherent. Try to be useful – will the message be helpful to person that is going to investigate production crash in the middle of Saturday night after your changes?

git_commit

Keep your emotions at bay. Sometimes you would like to shout and cry over the code you have to work with when committing. You can grab a few beer with your fellow developers after work and explain them in detail why your architecture is dumb as an ox. Do it in the bar, not in the commit message.

The Amount

How detailed should be the message? It depends on many things. If you are working on small two man project, and the second developer is right in front of you, there is probably no need to write a poem each time you commit. If you work on huge open source monster with hundreds of people you haven’t ever seen, nor had planning and review with, it’s a different story.

monk_at_medieval_writing_desk

If you need to write a lot about your change to explain it, perhaps version control is not the best place to do so. Reading commit message should quickly and precisely tell you what was changed and why, not explain in details the architectural nuances it is connected with. We have a documentation for that. There are people who read Clean Code chapter on self documenting code, misunderstood it  and are now trying  to sabotage any other form of documentation “because Uncle Bob said…”. No, that’s not what Uncle Bob said.

The Place

If the change requires detailed explanation, just point to it. Your product should be accompanied by some form of Product Backlog and most commits should belong to some kind of user story, task, feature or whatever you have there. I don’t believe it should be all of them, because sometimes you just randomly walk into small and ugly piece of code that you can safely fix ad hoc, since you are the Good Scout.  Assigning this change to any unrelated existing story is artificial, and creating separate story just for this change might take more time than performing the change itself. If your workflow requires that all changes need to have a story, perhaps you can have one story called Scouting or something like that. Before you start the story, it should contain a business description of what is to be done. During development, you might want to use issue tracking software to store more detailed explanations of changes than in the commit messages.

walddorf-attic-librarySometimes you might want to include some additional external documentation or knowledge base outside of issue tracking system. Perhaps you have some form of wiki, Confluence, Google docs or other form of organizing documentation and can describe why something happened in there. You might want to create a technical background to cover business story. Perhaps write down some problems you have encountered, motivate some choices you have made and list potential risks you see. You can discuss things with other developers on the project, ask decision-making people to make decisions or request comments.

Why are we doing this, again?

Just remember, that all this should be there to help, not to restrain or annoy. If it is not helping, don’t hesitate to change it or kill it. With fire, to be sure.

Happy committing!

commit-message

 
Leave a comment

Posted by on September 22, 2016 in Misc, Technology

 

Tags: , , ,

Git Intro

Entry 35

Since last time I finally showed you some code and mentioned storing examples on GitHub, let’s talk about underlying version control system and surrounding tools. Many of you probably used SVN as version control, especially if you worked for big corporation which are not that fast at adopting new stuff. Some of you perhaps switched to Git, maybe after leaving the corporation for smaller and smarter company. Well, that would be me right now :)

The System

logomark-orange2x“Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency” says the homepage.

Git is distributed. Everyone has his own copy of the repository on a local machine. You can commit to it and fall back to earlier versions without relying on central server as in SVN. What about the Holy Trunk then? In typical workflow there is a base remote origin repository, where all changes are pulled, acting more or less like the SVN server and source of truth.

Git is fast. Contrary to SVN, each time you change a file, Git creates new snapshot of this file instead of delta between two files and adjusts the commit tree accordingly. This can take up a bit more space, but makes branching incredibly fast. Since files are marked with their hashes, they are never stored twice, comparisons are very fast and it’s hard to lose consistency either by accident or on purpose. Git is not stupid too in regard of taking up disk space and bandwidth and has sophisticated data storage optimizations.

I remember the pain of switching branches in a project with 30 000 classes versioned under SVN. It’s not the case anymore.

The Host

github-markAs you probably already figured out, you don’t need to use any external host or server to unleash the power of Git. You can download it, create your repo and start committing, branching, checking history, comparing and doing all that neat stuff. At some point however, you might want to share your creations  with the world or just make sure that your repository won’t be gone if your hard drive accidentally dies.

By far, the most popular Git hosting service is GitHub. Its free for open source projects but you can pay to keep your secret endeavors hidden from the community. There are a lot of useful features like hooks, pull requests, comments, team management, various visualizations or Gist.

Another option, backed by Atlassian, is BitBucket. It has one advantage over GitHub as it offers free private repositories with limited number of users. If you are old school player, you can use SourceForge which supports Git for quite some time.

Trivia: currently GitHub is more popular than Pornhub (53th vs 60th place according to Alexa).

The Tool

sourcetreenewicon-300x300Since Git has a bit higher entry cost than SVN, in order to learn some basics, you can start with Git bash. When you get some grasp on how things work, and get tired of typing, I would recommend something more visual, like SourceTree from Atlassian.  It’s free, popular, powerful and intuitive. I’ve tried plugins for Eclipse and Intellij (yes! I’ve finally  switched to Intellij after 7 years of using Eclipse), but SourceTree is better. You can also check out the 5 reasons to use SourceTree blog entry.

Also, since I write a lot of Word stuff recently, and keep some of them under version control, I also enjoyed that SourceTree has out of the box diff on docx files. GitHub can’t do that.

Final Thoughts

Git might seem to be difficult and counter intuitive at first, but learning it is worth the effort in the end. It’s now a de facto industry standard and unless you plan to spend the rest of your career doing Cobol on IBM mainframe in some god-forgotten IT department of definitely non-IT company, you will probably have to learn Git anyway.

If you would like to read more, I can recommend two nice books about Git: Git Pocket Guide by Richard E. Silverman and Pro Git by Scott Chacon. Second one is available for free. There is also a good tutorial on Atlassian site and high quality courses on Pluralsight (if you are tired of random YouTube IT tutorial clips in heavily accented English).

 git

 
1 Comment

Posted by on September 15, 2016 in Technology

 

Tags: , ,

Angular Intro

Entry 34

Talk is cheap. Show me the code.

– Linus Torvalds

          I’ve talked about recruitment and clean code recently, but I haven’t shown you any (or almost any) actual code for some time. Time to fix this. In November 2014 I’ve written articles about GWT and Vaadin. Now I’d like to present you something similar on AngularJS, which seems to be the most popular JavaScript framework nowadays. And despite being JavaScript, it’s actually pretty good. Let’s take a look.

Overview

AngularJS-huge

          Angular is a JavaScript open source front-end, single page, web application framework maintained by Google.

          It provides a standard structure for front-end project part, like GWT, much as Spring provide standard structure for back-end part. Its simplification, because you can do the front-end in Spring too via Spring MVC, and the structure for entire project is also partly defined by Maven or other convention over configuration type build tool, but it’s an idea to start with.

          It is single page framework, also like GWT, meaning the front-end loads greedily, and later only contacts back-end to get necessary dynamic data, not to render entire html page as in server-side web frameworks like JSP or Vaadin. This makes web page more responsive and user friendly.

Under the Hood

          The idea behind Angular is to provide a standard project structure, so you know where to expect things when you approach a new project (Principle of Least Astonishment), and do as much dirty work for the developer as possible. The classic dirty work was tons of boilerplate JavaScript and jQuery code required to manipulate DOM, listen to events, update stuff etc. Angular decouples DOM manipulation from application logic and gives you two-way data binding for free. You will see that in the example soon. Also, Angular follows declarative approach, and provides you with plenty of small components you can easily configure and use on your page to do all the work for you.

          From the technical point of view – Angular is a script that interprets html page with Angular directives, performs dependency injection and gets the magic going, so that you don’t have to get your hands dirty.

Hello World

          Let’s look at the actual example. I’ve created a simple project, available on my GitHub. Feel free to fork it, clone it and play with it (and give it a star if you like it :). It uses Maven for build and Spring Boot for back-end. Easiest way to run it in Eclipse:

  • Clone the repository to your machine
  • Import -> Existing Maven Project
  • Project -> Run as -> Maven Install
  • AngularIntroApplication.java -> Run as -> Java Application
  • Check out at http://localhost:8080/AngularIntro/start

          It’s that simple. No installing and configuration of external servers, no deployment, just one Fat Jar from Spring Boot. You have all Eclipse and non-Eclipse settings you need to work with the project out of the box, namely:

  • Java compiler settings
  • Deployment assembly
  • Project facets
  • Conversion to AngularJS project
  • Spring application.properties

It is recommended to install AngularJS plugin for Eclipse for directives syntax highlighting.

          Similar to GWT and Vaadin articles, we are going to display customized Hello world message travelling all the way from front-end to back-end and back again. Let’s take a look at what makes the Angular magic work.

Module.js

var angularIntro = angular.module('angularIntro',[]);

Definition of main application module and its dependencies. For now, there are none, so we pass an empty array.

Service.js


angularIntro.factory('service', function($http) {
  var service = this;
  return {
    getGreetings : function(name) {
      return $http.get('/AngularIntro/getGreetings/'+name);
    }
  }
});

Basically a single method that performs http get request with single string as a name parameter, and returns a response object to grab onto.

Controller.js

angularIntro.controller('controller', function($scope, service) {
  $scope.greetings="loading..."
  service.getGreetings('world').then(function(result) {
    $scope.greetings = result.data.text;
  });
});

Controller uses Service to asynchronously fetch data from server and bind it to the $scope, so that View can display the result. At the beginning the greeting variable displays loading message, but after the call returns, the function executes, binding returned data to the variable. Since server is lazy, it will sleep for one second before responding to the request so we can observe the changing value on the View.

View.html

<!DOCTYPE html>
<html ng-app="angularIntro">
<head>
<meta charset="ISO-8859-1">
<title>Angular Intro</title>
			<link rel="icon" type="image/png" href="favicon.png">
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.js"></script>
<script src="Module.js"></script>
<script src="Controller.js"></script>
<script src="Service.js"></script>
</head>
<body ng-controller='controller'>
<table style="border: none; width:400px">
<tr>
<td>
<div style="font-size: 30px;">Angular Intro</div>
by <a href="https://howtotrainyourjee.com/author/">Gvaireth</a>

<hr>

<b>Asynchronous data fetch from server</b>
Wait for it: {{greetings}}

<hr>

<b>Two way data binding</b>
Type your name:
<input type="text" ng-model="yourName" placeholder="Enter a name here">
Hello {{yourName}}!

<hr>

Check out my <a href="https://howtotrainyourjee.com/2016/09/08/angular-intro/">Angular Intro</a> article for details.</td>
</tr>
</table>
</body>
</html>

Several things are going on here, let’s review all of them:

  • There is an ng-app directive that tells Angular that it should wake up, parse the page and perform all its mysterious shenanigans.
  • There is a <script> tag pointing to Angular engine script sitting tightly somewhere in the Google cloud. You can download it and keep locally if you are afraid that Google might collapse and close down the servers.
  • There are three more <script> tags pointing to our Module, Service and Controller JavaScript definitions.
  • There is ng-controller directive, telling Angular that this part of the page is backed by a specific Controller, thus sharing $scope variable with it.
  • There is $scope variable greetings surrounded by quite a lot of brackets. Brackets tells Angular that it should be evaluated accordingly. Its starting value is assigned in the Controller, and it will change when the server wakes up and graciously responds.
  • Finally, not really related to front-end to back-end conversations, there is a text input field with ng-model tag. It binds the DOM field to $scope variable, so when you start typing, the value will appear to the right. This is a classic example of data binding between two View entities without even bothering the Controller.

Simple, no? Let’s jump to back-end then.

spring-by-pivotal

AngularIntroApplication.java

This is the Spring Boot application core class, this episode is about Angular, not Spring, so let’s not get into details. Just know that you have to run this as Java application and Spring Boot will harness the power of its internal Tomcat server to host your application without giving a damn about deployment environment and all that boring stuff. It just needs Java.

MainController.java

Main Java controller maps our main, and so far only, View to context/start url, and responds to Angular Controller with simple object containing greeting line. It’s not exactly the Single Responsibility Principle example, but… Angular Episode here again, we are short on time in the back-end part. Also it’s so trivial that there is no point in creating separate Java service class just for damn string concatenation.

Final Thoughts and Some News

          I used to hate JavaScript and everything around it, mostly because I’ve seen a lot of crappy JavaScript code, but after getting to know Angular I toned down a bit. I mean JavaScript is still bad as a language, but Angular helps a lot by providing conventions and eliminating tons of boilerplate code. Also, you can use TypeScript or Dart with Angular instead of pure JavaScript.

          This article is meant as a starting point for the series. I’ll try to build something more using the simple example I’ve showed you as a foundation. More Angular features coming soon.

p.s.

          If you happen to be in Gdańsk, Poland  on September 29, you are welcome to attend my talk on Object-Oriented principles. Its free, you only need to subscribe on the even page.

p.s. 2

    I’ve changed the blog domain name from HowToTrainYourJEE.com to HowToTrainYourJava.com. Old one will work too for some time.

angular intro

 
Leave a comment

Posted by on September 8, 2016 in News, Technology

 

Tags: , ,

Embrace the Change

Episode 33

Everything changes and nothing stands still.

-Heraclitus

          Software changes. Technologies change. Build systems change. Deployment environments change. Requirements change. Markets change. Clients change. Some people refuse to change though. How to deal with all that fuss without losing sanity?

Wind of Change

          This week’s episode of How To Train Your Java is hosted outside of the usual place, namely on my company’s tech blog, right here. Enjoy :)

Sweet Sixteen

          By the way, if you happen to be in Wrocław, Poland in four weeks from now and you are not afraid of Polish language, you are welcome to join my talk on principles in object oriented programming. I’ve titled it Sweet Sixteen (since there will be 16 principles). Its free, includes beer and pizza, you just need to sign up on the event page, right here.

          In the next episode I will do something I haven’t done for quite some time. I will show you some actual code. Stay tuned.

embrace the change

 
Leave a comment

Posted by on September 1, 2016 in Agile, Sweet Sixteen, Technology

 

Tags: , , , ,

The Pomodoro Technique

Entry 32

          I was recently attending a talk about planning stuff, and one of the aspects of it was an introduction to time management method called The Pomodoro Technique.  I’ve decide to try it myself and share some insights here.

The Idea

                The idea is simple and involves a timer and some discipline.

pomodoro

  • Decide what should be done.
  • Set the timer to 25 minutes, the interval is called a Pomodoro.
  • Work on the task until the timer rings. If you get distracted, just write it down, but get back to the task at hand immediately. Try to shield yourself from any possible distractions as much as possible.
  • Take a short break (3-5 minutes), stand up, walk, get something to drink, do a quick exercise. Anything that is not related to the task and will help you clear your mind. Go to next Pomodoro. Repeat.
  • If you complete four cycles, take a longer break (15-30 min) instead short one. Repeat.

The Execution

                It requires some time to get used to. Especially if you find it difficult to focus on one task and constantly think about dozens different interesting things to do, like me. Before I stumbled upon the Pomodoro, I tried to work in 45-minute focus and 10 min break cycles. Like in school, more or less. However, it actually seems that 25/5 cycle is better for me. I’ve noticed that after longer cycles, I tend to drift away much more, especially towards the end. Also, school is over.

                20160823_161540Besides timing, there is an issue of shielding from distractions. I’m trying to shut down email, social media, phone and all that stuff, put headphones on. What to do if someone comes to your desk in the middle of Pomodoro? Well, it’s up to you.

                As a tool, I’m using tomato-timer. It’s simple and got all that’s needed. There are plenty other pages and a lot of mobile apps, some with fancy statistics, but I didn’t research them. It’s just a damn timer. When I get up from my desk I usually leave my phone, and I haven’t used a wristwatch since high school, so I usually mess the break timing. Before I leave though, I start the break timer on my computer. If it’s still on when I come back, I just mindlessly browse cats or something in the internet or play with radio controlled Lego excavator I keep on my desk. If I come back too late, well… I just hop onto another Pomodoro (shame… shame… shame…).

                Using timer has also an additional advantage. You don’t have to check the time periodically and think about whether you should take a break or not, asses your mental fatigue level, decide if you are in a good place to pause and all that stuff. When you hear the Pomodoro rings, just finish your current thought, line of code, sentence, or whatever you got there, set a break timer and get up. Or just leave everything and get up immediately if it works for you.

                In typical office conditions it might be difficult to sustain perfect cycles. There are irregular meetings, there are people that want to ask something in person, there are delivery guys that won’t show up at exact hours. There is The Flow. There are fuckups on production… Just don’t try too hard, remember it’s a tool to help you, not to restrain you.

                Some mentally old people might have objections that the Labor Code (at least in Poland) states that you should work 55 min and then you got 5 min break. Yeah, that might apply to a factory, not to software development. If your manager would make you fuss about that, tell him he should manage factory workers not programmers. Any smart company would understand that it’s just a number on a paper that HR has to keep signed in a binder, and we are here to get the shit done efficiently, not to sit at the desk for a given number of minutes a day. And, remind me, why would you want to work for a dumb company?

The Retrospective

                stay_focusedPomodoro works for me. Perhaps, to some extent, it’s a placebo to help you focus. You might think somewhere around “Damn I’m using a legitimate time management technique that has a name, so I should ignore this Facebook notification and keep working until the timer tells me to stop”. Intervals? People are different, some can focus for more than 40 minutes, but most probably can’t. Where is the efficiency threshold? I guess it requires some experimenting and might be difficult to measure. 25 minutes seems fine. Go ahead, try the Pomodoro. It’s healthy.

toothless-wallpaper-25

 
1 Comment

Posted by on August 25, 2016 in Misc

 

Tags: ,

I know what you committed last summer

Entry 31

            As promised, the continuation of Code of Principles is here. This time I’m going to talk about stuff that is less canonical and perhaps not so well known. Today’s motto is that you are not alone. There are strangers, psychopaths, users, fellow developers and good scouts out there.

Don’t talk to strangers

StrangerDanger_NeighbourhoodWatch_FINAL_ybg

            Let’s discuss Law of Demeter also known as Principle of least knowledge. Proposed in 1987 by Northeastern University, can be informally described in four bullet points:

  • You can play with yourself (naughty boy).
  • You can play with your own toys (but you can’t take them apart).
  • You can play with toys that were given to you.
  • And you can play with toys you’ve made yourself.

Which basically means that object should assume as little as possible about its environment, surroundings, its structure, properties and anything else, especially about internal structure of objects it’s manipulating. Classic violations of this rule are chains of invocations like this: a.getB().getC().doSomethin().getD().doSometingElse(); By the way, such style poses additional problems when resolving exceptions. Can you tell which invocation threw one exactly? Code following Law of Demeter tends to be more maintainable and adaptable. Following it strictly has some disadvantages however, like introducing time and space overhead needed to facilitate wrappers and auxiliary access methods.

(P)rinciple (o)f (L)east (A)stonishment

the-fuck-is-this-the-fuck-is-that

            Also known as (P)rinciple (o)f (L)east (S)urprise. Often used in context of user interfaces from the ergonomics standpoint, along with (D)o (W)hat (I) (M)ean rule coined by Warren Teitelman in the sixties. Regarding user interfaces, people have experience, expectations and mental models. Design should reflect that in being the least surprising as possible. This also applies to code. You should construct things in a way that are intuitive, obvious, consistent, predictable and boring, based on the thing name, location and other clues. Try to leverage existing techniques, standards and conventions as much as possible. What if your project already violates those? Well it depends, if it’s easy to fix, just fix it. If it’s harder, nag your Product Owner for budget to do it. If it’s too hard to fix, follow the bad conventions. Bad conventions are usually better than no conventions at all.

         Good example of intuitive stuff is a ParseInteger(string, radix) method present in many programming languages, that has a one-argument version that usually assumes radix to be 10. Notable exception where it doesn’t work that way is JavaScript, which is… well… JavaScript.

Write Code for the Maintainer

good_psychopath_rect

            “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” This is somewhat connected to the previous rule. Usually, code is written once and then maintained for a long time. Even if your creations brilliantly fulfill the Open Closed Principle, and don’t need to be modified, still someone has to understand what should be added where to achieve desired result. Think of people who are new to the project and will have to update your code, can they easily do that? Will you be able to do that after a year? When I was working longer on single project I had situations where after finding myself in some strange and scary place I would thought “What kind of moron wrote this crap? Hmm… oh…  it was me a year ago…”. Don’t make me think too much. It hurts my brain.

            Also, Brian Kernighan once said: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it”. Keep that in mind.

Boy Scout Rule

goodscouts

            “Leave the code better than you found it”. Boy and Girl Scouts have the rule about camping, namely, they should leave it cleaner than they found it, meaning not only taking care of mess they made, but also of the possible mess they encountered originally. This translates directly to software development. When you arrive at location in code, make sure you don’t leave a mess, as well as try to take care of the mess you have found in the first place. This is a bit tricky. Firstly, you can fix something, spot another thing, fix it, spot another thing and fall into the trap of never ending cleaning further and further away from your camp. This is dangerous, since you stray away from your task goal and thus your sprint’s success might be in jeopardy. Secondly, it’s sometimes risky in legacy (nice word for “shitty”) systems. If you lack automatic tests and wander outside of the area of your task, which will be tested manually, you might break something without noticing. In theory IDE support for automatic refactoring of static language is quite impervious (but not always), however when technologies collide no one is safe. You might change an enum with all its occurrences in Java, but maybe there is a nasty JavaScript code that uses it recklessly on the frontend and boom! you are screwed.

            Boy Scout refactoring should be safe and small, and/or it should happen around the code you are working with. I remember the situation when I walked happily into my manager’s office saying “you know what, I threw away that crappy piece and written it from scratch nicely!” and instead of joy I saw grim face and heard “I didn’t ask you to do that…we have budget and stuff…”. I had to explain in details that I was building upon that change and I can deliver things faster now, and it was safe and good thing in general. If you spot a bigger refactoring opportunity outside of scope of your current task (say more than one hour of coding, depending on your team’s work agreement, deadlines, sprint tension and all such things), don’t rush into being good Boy Scout, ask your Product Owner if it’s okay and add it as a separate story to sprint. Remember, we are not here for the sake of art (unfortunately) but to fulfill our client expectations. We can shape those expectation too of course.

Finally

            Think before you commit. Do they know where you live? Should you be scared if they do? Don’t worry, stick with the dragon blog and you will be fine ;)

i know what you comitted

 
1 Comment

Posted by on August 18, 2016 in Clean Code, Sweet Sixteen

 

Tags: , ,

Code of Principles

Entry 30

            Enough about recruitment, let’s get back to code. This article is (more or less)  going to be a continuation of Rock SOLID Code. I’ve talked about five principles forming letters in the SOLID acronym, now I’m going to talk about further set of well known (hopefully) programming (and not only) concepts.

(K)eep (I)t (S)imple, (S)tupid

kiss problem

            “Everything should be made as simple as possible, but not simpler.” Albert Einstein once said. KISS acronym was coined by Kelly Johnson, U.S Navy engineer in the sixties. Basically, simple thing doing the same job as complex thing is better. It’s easier to understand which means being less error-prone, easier to maintain, cheaper and more efficient. Always try to come up with simple and intuitive solution to the problem. Sometimes it might be more difficult than coming up with difficult one! There are people who are proud to invent overly complicated and “smart” solution that only they can understand. They should burn in hell. Every time when I see a class name containing “smart”, my inner warning light turns on. Why the author had to use word “smart”? Is there a nasty hack somewhere there? Is there a dirty non-standard solution? Does he need to prove that he is smart by constructing something incomprehensible to others? Where does he live if I had to track him down? Tick… Tock… Tick… Tock….

(D)on’t (R)epeat (Y)ourself

dry problem

            Every piece of knowledge must have a single, unambiguous, authoritative representation within a system as formulated by Andy Hunt and DaveThomas in The Pragmatic Programmer. Violation of this principle is called (W)rite (E)verything (T)wice, or (W)e (E)njoy (T)yping. The idea is that every piece of information in the code, be it data or algorithm, should be written once. This way we avoid verbosity, copy-pasting and risk of inconsistencies and errors. It is strongly connected with The Abstraction Principle which states that we should aim at finding common characteristics of fragments of code and abstract them, thus reducing code duplication. However there should be balance between avoiding duplication and over-complication of the system. I was once the developer who couldn’t stand looking at one duplicated line of code, and tried to abstract it as much as possible, which sometimes lead to overblown class diagrams or myriads of too small methods. But I’m cured now. There is also a rule, somehow relaxed, called Rule of three mentioned by Martin Fowler in book Refactoring, which says that code can be copied once, but if it is used three times, it should be extracted to separate procedure, class or whatever. There is no silver bullet here, use your judgement.

(Y)ou (A)ren’t (G)onna (N)eed (I)t

yagni problem

            “Always implement things when you actually need them, never when you just foresee that you need them” said Ron Jeffries, co-founder of Extreme Programming. It emphasizes writing as much code as needed to complete the feature or task at hand. In times of agile development, rapid prototyping and ever-changing requirement, it’s often risky to assume much about future. Expectations change, technology changes, ideas change, market changes. Sometimes you conceive a brilliant framework for your application that will take two months to develop and at the end turns out to be useless because client changed his mind, the scope got reduced or something similar happened. This doesn’t mean of course that you should dump creating elegant, abstract and flexible solutions over loathsome copy-pasted pile of crap. Just start simple, with what is needed to achieve goal of story or sprint, increment, refactor, experiment and shape suitable abstractions as complexity grow. That’s called emergent design, and it works providing you are disciplined to refactor stuff.

Minimize Coupling

coupling problem

            “Coupling is the manner and degree of interdependence between software modules” reads dear old Wikipedia. Loose coupling is desirable property of application modules, since it makes them easier to reuse, easier to test in isolation and less likely to break down after modifications. Introducing changes to tightly coupled systems tends to have a ripple effect, where new feature causes shitstorms (or solid-waste-atmospheric-disturbance, if you like) in random places, often remote from where the change originated (sounds familiar?). Often though reduction of coupling comes at a performance cost related to message transmission / translation / interpretation. Sometimes, for some critical points of the system, trade-offs have to be considered. You may think of low coupling of modules in high-level terms as good encapsulation. In modules, much as in classes, it’s good to hide implementation details and only expose clean and elegant interfaces.

Maximize Cohesion

cohesion problem

            “Cohesion measures the semantic strength of relationships between components within a functional unit” or, simply put, refers to the degree to which the elements of a module belong together. High cohesion is good, because it improves code readability. When stuff is where it is supposed to be, and fits well together with its neighbors, it’s easier to understand. Cohesive code is likely to be easier to reuse. There are several types of cohesion, going from the worst to the best: Coincidental, Logical, Temporal, Procedural, Communicational, Sequential and Functional. While coupling problems are easy to detect automatically via static code analysis, cohesion is much more elusive, subjective and difficult to assess, thus requiring human insight.

            That’s it for now. In the next episode I will continue the topic and dig into some less known and more informal principles of programming.

7lZE5AN

 
2 Comments

Posted by on August 11, 2016 in Clean Code, Sweet Sixteen

 

Tags: , , , , ,

Software Developer Interview: Your part.

Entry 29

            Now you will ask questions. Lots of them.

            As I have mentioned in the previous article, job interview is a symmetrical process. There are two entities – the Company and the Developer that meet in order to find out if they want to start a collaboration. The company will try to check if you have suitable skills, talents and how you handle different situations. They will ask you tons of questions. And you should do the same – carefully and thoroughly find out if the are suitable for you in each aspect you care about. Basically, you should have the same amount of time for your questions, as they had for theirs. Symmetry and honesty.

Project

            When you have technical people in front of you, ask them as much as you can about the project you are going to participate in.

  • High level business overview as seen by developer.
  • Technical overview.
  • Technology stack and plans for it.
  • Legacy problems, and if present, how do they deal with them.
  • Software development process: do they have Agile? Scrum? Scrum-but? Waterfall?
  • Do they have Continuous Integration? Automatic tests? Deployment at the push of the button?
  • How do they host their stuff?
  • How big is the project? How old is the code and how many people worked on it?
  • What tools do they typically use? What IDE? Can you use your favorite IDE and tools?
  • Will you have the level of autonomy you want?

Environment

            How does your potential future office and workplace look like? Do you like it? Can you spend there 8 hours a day 5 days a week comfortably?

  • How big is the team? Is it distributed or sits in one room? How many teams are on the project?
  • What are you working on? Is it a laptop or workstation? Is it powerful enough? Does it have SSD drive? Will you be given two big displays? Or is it just a thin client to virtual machine hosted in another country? (good luck with that).
  • Do you have control over your computer? Can you install whatever you need for work? Or you have to wait for management approval for simplest and most obvious things?
  • Are there any restrictions in access to web pages? Will you have to wait 3 days until you will be given access to technical blog with information you need for work?
  • Can they give you tour around the office?
  • Do you sit in a room or in an open space? Or even worse, in “smart” office where you don’t even own your freaking desk?
  • Do you like view form the windows? (like, physical ones… you know)
  • Is there a dress code? Is it okay with you? If tech guys came to interview in suits, you should probably run (I would at least).
  • Is there a free / affordable, convenient parking space?
  • Suppose, you like to cycle or run to work. Is there a shower in the office you can use?
  • Is there a flexible approach to work hours? Can you work 6 hours one day and 10 on another one? Can you work 35 hours one week and then 45 hours another one? Can you leave office for 2 hours and later stay 2 more? Let’s assume that those fluctuations won’t interfere with duties to your project like meeting or deadlines, of course.
  • Is there free coffee / tea / milk other stuff in the kitchen? Some companies will even provide you free breakfast or lunch. That’s a nice touch and you can avoid queues to the “sandwich guy” or thinking about how do you not starve to death today.
  • Are there mugs, glasses, plates, cutlery, dishwasher, microwave oven? Place to sit?
  • Do they have physical library? Access to online libraries you would be interested in? Chill-out room? Fun room? Do you like to play table football with your mates? Do they have it?
  • Do they have displays with build status or other relevant stuff on the wall?
  • Can you order a package for the company address and have it handled by someone if you are unavailable to pick it up?
  • Is it software company or they just have IT because they “have to”?
  • Is it even technological company or are they working in totally unrelated field? Find out about how they truly perceive software development and if you are comfortable with that (feels like necessary evil? – run).

Money

            Let’s talk money. There is a specific number regarding your salary, but there are a lot of other things to consider.

  • Are there any bonuses? What are the conditions and average numbers? A company offering lower salary but higher bonuses might overall give you more cash. But it might be tricky.
  • What are the other benefits? Sport cards? Private health care? Cinema tickets? Phone? Laptop? Car? Jet? (ok, maybe I’m aiming too high here, but you know what I mean)
  • Will the company pay for your certifications or external training if you need / want one? Will they pay for conference in another country and let you go in your work hours instead of forcing you to take leave of absence?
  • What kind of contract is at stake? Do you like to be an employee or one-man enterprise? Can the company offer you what you want?
  • How much time do you need to get to work? Remember time is money. An additional hour spent on traveling to office is equivalent of effectively being paid over 10% less per hour of your time and not getting any experience out of it.

Boss

            If you are interviewed by a person who is going to be your superior, you should make sure you will get along. Does this person have technical background? Or speaks only Excel? Ask questions to determine his / her behavior in certain situations and make sure you like the answers. I was once in an interview with a guy who was supposed to be my future boss and in the middle of it I knew there is no way freaking this is going to work. Some people just have a bad aura (or should not be allowed to manage anyone). Dump them immediately while you still can.

Future

            Do you see yourself in this company in the future? Is there a path you can follow? Or maybe this company it’s just a step in your own path and you are not planning to stay here for long. It’s fine, just think what your expectations are and if they will be satisfied.

Final thoughts

            Yes, that’s a lot of issues, and some of them might sound silly, but we are talking about the place you are going to spend over a half of your awake time excluding weekends. You should feel good there in all aspects you can think of.

            Basically, if you decide to change job, don’t fall for the first or second offer you are given. Try to get several (perhaps 4 to 10 depending on how much time and determination you have) interviews in relatively short time (2 to 4 weeks seems to be reasonable). The list of question and issues I came up with is my personal preference, and things I care about. You might have an entirely different list. Just have the damn list! Prepare your questions, ask them, dig deeper, observe reactions, note answers, compare, prioritize, think. Sometimes you might want to call some company again to clarify something or to negotiate. Find out if you have colleagues or they have colleagues that are working / worked in the company you are thinking about. Talk with them. Research the online opinions about company, are they favorable?

            Sometimes it’s hard to come up with a verdict, so just try to trust your gut feeling.

Good luck!

software developer interview your part

 
2 Comments

Posted by on August 4, 2016 in Misc, Recruitment

 

Tags:

Software developer interview questions: The soft part

Entry 28

            Soft is not a short from software here. In the previous article we went through technical aspects of Java developer job interview. This time we are going to explore the non-technical part or soft part or HR part or however you want to call it (it’s not just Java developer now, of course, but software developer in general). Sometimes you will talk with your potential team leader, project manager, line manager, other kind of manager, someone from human resources department or just a guy from dev team (hey, they can talk too!). They will try to find out if you will fit the organization, project or, in general, if you are the guy they would like to work with. I feel that developers tend to trivialize this part and think that if they are technically strong, nothing can stop them. However soft skills and personality plays a decent role in the recruitment process. After all, no one wants to work with an asshole, even if it’s technically brilliant asshole.

Up to the point

            So, I’m going to try to recollect these types of questions I’ve been asked on my recent interviews. As before, I’m not going to answer them, partly because I’m lazy and partly because sometimes there is no right or wrong answer.

  • Why are you changing job?
  • Name your three greatest advantages and disadvantages.
  • How would you describe your perfect workplace?
  • What do you expect from your future employer?
  • What motivates you?
  • Where do you see yourself in five years?
  • Describe a conflict situation you were in and how was it resolved?
  • What was your greatest fuckup in work and how did you handle it? (the choice of words may differ of course…)
  • How would you organize a newly formed team as a senior developer?
  • How would you react if your teammate is late with his tasks all the time and does private stuff or just nothing during work hours?
  • How would you convince me in one sentence that you are the right guy / gal for the job?
  • What do you know about our company?
  • Do you like to work in SCRUM? Why yes / no?
  • Imagine that at the end of the sprint a manager (or better: high manager) storms into devs room and demands some last minute feature to be included in the release. You know it’s too risky to do that, how would you react?
  • What software development book have you read recently and you can recommend?
  • How do you keep up with latest technologies, trends and stuff in the industry? What’s your main source of information?
  • Do you have some private software projects or contributions to open source? Tell me about it.

Brainteasers

Some people in this part like to give you abstract questions, brainteasers or puzzles to solve or just to see how you would approach solution, how creative you are and if you can think outside the box. Some examples:

  • What can you do with a drinking glass? You got one minute.
  • How many golf balls would fit in a bus / this room?
  • How many gas stations are in this town?
  • How would you measure the height of [tall building name]?
  • Burning Rope Problem (how original…)

Communication

If you are not native English speaker, you will usually be tested for your language skills. Typically they will ask you to describe your work experience, talk about your hobbies, or perhaps answer some of the previous questions in English. You might want to review that too.

Is there more?

Again, internet is full of questions and answers.

Books I’ve mentioned in previous article are mostly focused on technical side, but some of them contain a “soft” section too.

Besides I’d like to point out one particular book relevant to the subject. The Clean Coder: A Code of Conduct for Professional Programmers by Uncle Bob, not to be confused with Clean Code (worth reading too).

The Clean Coder tackles software craftsmanship from different angle than Clean Code. It cover ethics, attitude, prioritizing things (not only backlog items), dealing with pressure, corporate bullshit, different types of difficult people and other stuff. Go for it.

At least one more!

I have at least one more recruitment topic I’d like to cover. We talked about questions you might be asked as developer, we should talk about question you should probably ask your potential future employer. They want to check you, you want to check them. Symmetry.

See you next time :)

interview soft part

 
1 Comment

Posted by on July 28, 2016 in Misc, Recruitment

 

Tags: ,