DEV Community: Rickard Engberg

How far should you take clean coding?

Rickard Engberg — Mon, 23 Sep 2019 08:36:54 +0000

I've been thinking about something for quite some time. I'm a strong advocate for clean coding, and that a professional programmer should be allowed time for doing their job right. With that, I mean fixes and features should be done cleanly, and, if needed, legacy code adjacent to what the programmer is working on should be refactored (within reasonable limits). Indeed, certain levels of refactorings and renovation of legacy code should be included in the estimate for the story.
However, now and again, reality happens. Perhaps a bug was found, and it needs to be corrected, tested and distributed asap. There might not be enough time to do the refactoring that part of the code you're in so desperately needs. Alternatively, given the limited time frame, you may not want the risk a possibly complex refactoring adds. Should a professional programmer still enforce clean coding principles? At what cost should these principles be enforced?
There is always the option to make a quick fix, test it and ship it, but also write a story for the backlog on the need for renovation. Of course, we all know how hard it can be to get that story prioritised and scheduled for action.
I want your views on this, so please join the discussion.

Please continue (or comment) the following post...

Rickard Engberg — Tue, 27 Aug 2019 16:12:03 +0000

When the agile development methodology was invented some 20 years ago, it was invented by developers for developers. In the early days, Scrum was formed to manage the development of large systems by breaking them down into smaller parts. Sprints. The breaking down was made by developers, for developers.
Scrum was a development project management methodology, driven by developers and used by developers. Today, Scrum is managed and driven by managers, not developers. Furthermore, it’s become a marketing strategy. We work agile, is common in modern development consultant firms’ pitch lines.
Most project management methodologies have succumbed to this, or they will. They’ve been made into a form of management, and as they are assimilated by the managerial layer, they are losing its fundamental force and appeal with developers, and, consequently, their usefulness.

What to ask a presumptive employer?

Rickard Engberg — Mon, 27 May 2019 17:53:14 +0000

I'm thinking about something that maybe you can help me out with? When you're looking for a new job and get invited to an interview, usually what happens is that the presumptive employer starts asking you a bunch of questions about your career, experiences etc. Sometimes they even make you write some code or ask you to solve some programming problem (if it's a programming job you're interviewed for) at home. Maybe they even check out your public repos on Github (or some other source code platform). And there's nothing strange about that at all.

The point I'm getting to (and that I've been pondering for a couple of days) is that it's often mostly all about you. Yes, they likely did the two-minute company introduction and introduce Paul who's a developer and is sitting in on this interview... But when it comes to the code writing, the aptitude tests and the probing of days gone by, it's usually just your experience and your days gone by that is of interest.

Why is that? The last couple of interviews I've been to, I asked the employer a bunch of questions. I was the one who asked most questions. And even then the last one (before my current job) didn't work out very well.

I'd usually say, that when I'm invited to a company for an interview, I go there to interview them. Not the other way around. Perhaps the situation for developers is different in other parts of the world, but in Sweden, senior developers (or any developers for that matter) are very sought after. I heard someone say there's a shortage of about 50.000 developers in Sweden. So, perhaps it's easy for me to say all this.

Perhaps there should be an aptitude test for companies trying to hire you? Well, there is one, the Joel Test, but I think it's kinda lacking for use on a job interview.

Well, so I have a question for you. Well, I had two, actually, but I forgot the other one.

What questions do you ask the company that's interviewing you for a development position?

I'll start you off with a short list. Some of them I got from the Joel test. It's not in any sort of order, I just jotted the points down.

Do you have meaningful sprint planning and backlog refinement meetings?
Do developers have quiet working conditions?
Do developers have their own desk?
Can developers work from outside the office?
Are developers administrators on their work stations?
What are your people turn over?
What source control system do you use?
Can developers use their own tools? Phone, laptop etc...
What project methodology do you use?
What progress board or tracking system do you use?
Are internet all locked down on the company network?

An odd post about, well... I really don't know

Rickard Engberg — Tue, 21 May 2019 15:19:24 +0000

So I'm at a fun place in my professional life. At the tender age of 52, I've started looking for what I want to do when I grow up. Making a career isn't as important as it was when I was 20 or 30. The kids have moved out, and living expenses are suddenly far less than my income. I never thought I'd say that.

I write code for a living using my preferred programming language, it's summer, and there's ice-cream just across the street from where I work. Without the hassle and stress of career goals and deadlines, I'm pondering my options and opportunities.

One thing I'm doing is reading and blogging about clean coding. Well, I read about a lot of stuff, but concerning tech and computers, it's mostly about clean coding. That's an exciting field in programming, and I'm trying to learn all I can by, oddly, teaching it to other people. Or perhaps that's not so odd after all; teaching is about talking about stuff, discussing stuff and generally thinking about stuff. And I think a lot about clean coding.

One cool thing about clean coding, I think, is that it's about writing clean code (duh), and to me, clean code is beautiful code. I've always been more interested in the code itself than in the functions of whatever program I'm currently working on. That's probably why my hobby projects never get finished. My oldest one is going on close to 30 years and surely 20 editions (I say editions because I usually start over rather than continue on the previous version when I get into the mood to work on it).

So, beautiful code, what is that anyway? I don't know, but I think it's like the feeling a painter or a musician gets when the current piece of art is finished. I bet they can't really say why that piece is suddenly done. It just feels done, feels right, somehow. When I get that feeling, I know the code is done. The program might not be, it seldom is, but the code is done and I usually don't touch that code again. I just let it sit in a repo on Gitlab waiting for better times.

Sometimes, before I do the final commit (which I don't really know is the final commit at the time) I show my code to my wife. She understands none of it, but she likes the indentation. She likes the waves of the program structure, and I agree, getting that waving indentation line is really satisfying. As is getting all the statements, variables, class names, method names etc correctly camel-cased, white-spaced and, you know, just exactly right.

I have never printed and framed a piece of code, but thinking about it I'm sure one could do a really nice painting from a piece of nicely indented and well-written code. When I talk on the subject of clean coding, I like to say that a well-written program is like prose. (It's not my saying, I picked it up from the book Clean Code. I just like to say it). So how would a painter paint a piece of prose? I have absolutely no idea (just as I have no idea where this post is going).

I wonder what programming language is the best for that kind of programming art. My preferred language is Pascal, and Pascal makes for a really nice visual experience. More so than C# in my humble opinion. c++ is just messy to me, Java too but perhaps less so than c++. HTML and CSS (if those can be called programming languages) are very hard to format nicely, I think. Assembler has a nice line to it, those vertical columns appeal to a sense of order. SQL and its various dialects and procedural languages don't go well at all with the artfulness of programming, even though stored procedures can be rather cleanly written (except for MS SQL Server procedures, since MS choose a very odd way of doing if-begin-end).

I started rambling about growing up and going over what I've just written, it seems I have some ways still to go before I find out what I want to do when I grow up. But there seems, at least, to be options and opportunity. Hopefully, there are for you, dear reader, as well. Options and opportunity, that is, of whatever is in your future.

But whatever you do and whatever happens, always write beautiful code!

Code Reviews

Rickard Engberg — Tue, 21 May 2019 04:37:02 +0000

If you're only going to do one thing, and one thing only, in regards to make your and your team's code cleaner, it is without a doubt (in my mind) to start review every code change that enters your programs. No, code reviews in itself do not create cleaner code, but it does promote following the paradigms your team deliberately or not have agreed to follow. And that is a considerable step towards clearer code.

How so, I hear you ask. The team, you may argue, might not have adopted the correct clean coding paradigms. Or the team might not even have thought about what clean code is or how it should be implemented. Or why?
Well, here's the thing. While there are a lot of guidelines, tech and principles to guide you in creating cleaner code that you and your time might think you know nothing about, I'd wager a buck or two, that you already do a lot of clean things.

You might already

choose good variable, class and method names
remove redundant code
remove obsolete comments
use specific code patterns for common solutions

But all the things you do, individually as team members, may differ from how other team members would do it. Quite often, team members of a team have a good grasp of how to write readable and maintainable code, but these methods aren't synchronised between team members.
Or there may be new team members that haven't yet come to terms with how the code is written in your team.

Enter code reviews

When you start reviewing every code change that enters the source control, you not only review for bugs or mistakes, but the reviewer will also check for readability and maintainability issues. Does this variable name describe what it holds? Is that redundant code? Why aren't you using that generic class we have in this or that library?

A good code review is not just about finding mistakes, it's about spreading information and knowledge across the team. It's about synchronising team members, so they know what principles, guidelines and patterns to follow.
It's about jelling the team together, making it more effective and productive.

So, how to get started reviewing code

A couple of common concerns about reviewing code

We don't have any code reviewing tools, and we need to evaluate which to acquire
Should all code be reviewed even if only a typo of a label is fixed

There are many very nice tools on the market to help you do code reviews very easily. They often come with whatever source code repository platform you choose, Bitbucket, Gitlab or whatever. And it can be a handful to evaluate them and get the organization and the whole team to agree on which to use.

But here's a (not so secret) secret. You don't need a tool to review code. You have an IDE, don't you? It may be Visual Studio, Eclipse or just notepad. Tap a colleague on the shoulder and ask him or her to come over to your work station and go through to code together. That's a code review. And not only is it a code review, but it's also a session of pair programming.

And yes, all code should be reviewed. Even just a typo. It shouldn't and mustn't be up to the programmer to determine what scope of changes should be reviewed or not. Every single change to the code must be reviewed to enter the code base.
But won't that result in a gigantic load of code reviews? If every single change must be reviewed? Well, no. Small changes to the code are very fast to review, probably just a few minutes of work. Larger ones, of course, are harder to review. A suggestion for reviewing larger code changes is to do them as a pair programming session.

Read more articles like this on my blog https://codingcleaner.com

Coding Cleaner

Rickard Engberg — Tue, 14 May 2019 07:12:59 +0000

What is clean code?

Some of you may have heard the concept of Clean Code. It's been around a while and is often talked about by people like Robert C. Martin, and you may have read his Clean Code book series. If you haven't you should. There are a lot of books to read about clean coding, and if you're not a huge book reader, you can learn much about the subject online on blogs, youtube and by colleagues and communities such as this community.

So, what about it? What is Clean Coding? Well, it could be many things, depending on your team, on you or even on your company. Some teams enforce Clean Coding more rigidly than others, some don't care at all. If you'd google it, you'd find a lot of posts on coding principles and code patterns, and while that is very important to build clean, maintainable computer programmes, there is one thing I think of above all else when people ask me what clean coding is.

Readability.

The code should read like a book or your favourite prose. It should be correctly formatted, be nicely partitioned and you should get a grasp of what the code does in a very short time. Think about it, over a program's life span (yes, I use the word program as, in the end, all we programmers do is writing programs) of all from months to decades (the oldest program still maintained I've heard about first hand is a COBOL program that was started 1967, so it's over 50 years old now), maybe 20 % of the time spent working on it is writing changes to it. The rest, 80 %, is spent trying to understand it.

That's where clean coding comes in to play. If we could decrease the understanding part of programming by, say by a fifth, we'd reduce the part of trying to understand a program to about 60 % and increase the time spent doing what we all love - programming - to 40 %. Wouldn't that be great?

So, how can we achieve that? Well, we could agree on a way to make the code more readable. As it's the reading/understanding process of programming we want to decrease, it's the readability we need to increase. I'm sure, that if you've ever been on a jelled team (a team that's really knitted and works well together), you've noticed that one of the reasons for successfully writing solid, bug-free, maintainable code the team has adopted (or deliberately agreed on) a way to write the code; patterns, variable- and method naming, coding principles like the single responsibility principle and so on.

Wouldn't it be great if you could pick up a program on your new job, open it in your favourite editor, intuitively find the main procedure and think -'Hey, this is well-written code, it'll be a blast to work on this'.

That's not Utopia. It's not unachievable, neither for old, legacy code nor for shiny new programs. There is a code of conduct that can be adopted by your team to achieve this goal, and I'd wager you're already using some of them. The list of things to start to get coding cleaner is very long, but there are a few quick things that you and your team can introduce if you don't already do them:

Start code reviews
Clean up obsolete commentary, commented out code etc.
A naming policy; name variables, classes, methods and constants well, so a reader instantly understands what they do or hold.
Get rid of all hints and warnings from the compiler.
Refactoring to remove redundancy and duplication.
Separate different functionality into modules and classes.
Honouring code patterns agreed upon by the team.
Tests
Get GIT!

The list is a brief one off the top of my head, and it may seem odd to you that GIT is the last item and something so simple as code reviewing is first. There's a reason for this. It is sorted heavily on Easiest-to-implement-first. While I think that GIT should top any list of getting coding cleaner, it can be very complex to introduce. Switching from a previous version control scheme to a new one (as I firmly believe any team that does not use GIT should do, regardless of what they're using now) can take time both for the team members to learn and for the team to agree on a strategy (where git flow would be my recommendation).

As for the other items on this list, starting from the top. Reviewing code is an absolute requirement for maintaining clean and readable code in a team. No changes to any code, regardless of how small, should ever be committed to develop (or whatever your development branch is) without having been reviewed by someone else on the team. Never ever.

I was introducing this concept to a team at a previous employer and was approached by one of the developers after a glass or two at an after-work watering hole. It appeared he'd been working up a muster for a while and said,
-'Are you really serious that every change should be reviewed?'.
I answered, -'Yes, I'm really serious'.
-'Even just a change of spelling on a label', he continued.
I said, -'Yes'. He wasn't happy, and we didn't agree that evening, but the fact of the matter is if you're to introduce code reviews on your team successfully, you absolutely need to review everything. Luckily, that isn't so hard. A change that small takes all of 30 seconds to review.

-'But, we don't have to tools to review the code', the sceptic will object. -'We need to get GIT running, and bitbucket or Gitlab or Github...'

No, you don't. You use an editor to write your code in, don't you? Well, just tap a colleague on the shoulder and ask him or her to review your latest changes. Go through them together, and you'll both learn something.

Items 2 and 4 on the list are so simple to introduce so there really isn't a reason not to do them. At most, a 45-minute meeting (with a clear end objective) would take care of that.

The rest of the items will take longer to implement, so make a plan for implementing them. If you don't they'll not get implemented.

You may again flinch at the ordering of items 5 to 8, especially that tests come way after refactoring. How could you possibly refactor without unit tests? Well, for one thing, the tests items aren't just about unit tests. It's about a testing strategy (which I will add my thoughts on in a later post). And a refactoring can be done without unit tests (jeezus, did I just say that). Well, I'm not talking about refactoring 30 % of the application here, I'm talking about getting rid of redundant or duplicated code. To change variable or method names to describe what they do. It can be done if you're careful and is thorough about telling the testers what to test for after you're done.

Well, that's it for now. I'll get into more on clean coding here and on my blog https://codingcleaner.com in the future. I'd really like to get comments and thoughts on this. These are my point of view on clean coding, or at least the tip of the iceberg. And if the goal is for the programmers guild to adopt a common way of writing readable, maintainable program code, we need to discuss every aspect of it and there needs to be a lot of people to engage in this cause.