Sceptical Meerkat
Random thoughts of a software developer
Sunday, 6 October 2019
Tuesday, 8 August 2017
Left-liberal totalitarism.
This is the text that got a software engineer fired: Google's ideological echo chamber
Google's Ideological Echo Chamber (pdf)
Is there any different between Communist Russia circa 1970 and today's Silicon Valley? I can't think of any.
Google's Ideological Echo Chamber (pdf)
Is there any different between Communist Russia circa 1970 and today's Silicon Valley? I can't think of any.
Monday, 23 January 2017
Real "Pair Programming"
Looks like North Korea is leading in introducing Pair Programming to the Agile software development teams:
Tuesday, 17 January 2017
Code reviews
Some thoughts I have on how to organise code reviews when you are a team leader (at least this is what I try to follow):
- Code changes need to be reviewed before merging it to Master branch and before testing.
- As a leader, code review all changes done by other people, but ensure that everybody else is involved in code reviews (others don't have to code review everything, but ensure that everybody does some code reviews).
- Ensure that your code is always code reviewed by your team members and always react positively when a problem is found with your code, make changes to the code you written based on advise of the junior team members. This will ensure that the team members don’t see a problem someone found in their code undermines their position.
- Don’t nitpick, accept that different people write code differently. Insist on modifications to the work you reviewing only in a case of a bug or if the change that does not fit with overall design. Be polite and try to explain the reason.
- Have coding standards and ensure that tools for automatic code formatting are used (in case of Java IDEs both Eclipse and IntelliJ allow this and you can copy formatting rules between computers — when someone joins the company, just send them the formatting setup file). This will prevent “formatting wars” and comments about formatting.
- Have static code analysis tools run as part of CI (e.g. Sonar), this will reduce disagreements — psychologically it is easier to accept criticism from a machine then from a fellow developer.
Thursday, 5 January 2017
Joys of legacy code
I have recent stumbled across this text: http://typicalprogrammer.com/the-joys-of-maintenance-programming/
Somehow it resonated with me. I started working as a developer
in early 1990s and I have done it all – “green field”, maintenance, you name
it, I had my share of creating software from scratch, I had experience of re-architecting
existing software and I experienced fixing bugs in code that was written before
I learnt how to program in a language nobody wanted to learn anymore.
What I have noticed that as time goes I enjoy maintenance
development more and more.
Often I find developing software from scratch to be too easy
and boring. I find there is more challenge in making legacy code “great again”.
I can understand why those, who have never had a chance to
do it, are dreaming of “green field development” and writing systems from
scratch using latest and coolest technologies and methodologies. Many
developers believe that if only they were given a chance, the software they
will design will be much better then whatever they work with. Unfortunately, it
is not the case…
I would say that the majority of developers are able to
write a new application that will more or less do what is required. But in most
cases, couple years down the line, their code will probably be found by “the
next guy” to be even worse then the one they love to criticise. I think only a minority of programmers can actually make an old code with layers and layers of changes to be
nice again.
Friday, 23 December 2016
Polyglot programming and micro-service architecture
Recently I was trying to understand how a micro-services
based system was designed by looking at the source code. The code was developed
more or less recently in a company for an application that provided web access
for customers.
It was a service in Kotlin calling a service in Scala, which
in turn was calling a service in Groovy, which was calling a service in Java….
At that point I lost the will to go any further.
On each step one needed to figure out which other service is
called (this is not easy if you have a lot of different services and very
limited documentation) and then to try to switch to a different language and a
different frameworks with different conventions (e.g. where a controller to be
found etc.).
Unfortunately I have a very strong suspicion that this
madness is there to stay. The problem is that micro-service architecture gives
developers a chance to write software from scratch (something many people, who
have never done it before, would love to do and who usually do it awfully due
to lack of previous experience) and it gives an excuse to learn a new
programming language while been paid by the employer to do it.
Saturday, 17 December 2016
Pair Programming – what’s in it for me?
There are many advocates of Pair Programming explaining why
they think this way of organising software developers’ work is good for the
company. But I have not seen much explanation why it might be good for a developer.
We, developers, usually enjoy what we do and care enough for the success of the
projects we work on, but I don’t think many of us would get up in the morning
and commute to our place of work if there was something for us as well – we
would like to be paid well and we like to have a career. This means that our
choices are not defined by what good for the company but also what is good for
us personally.
Pair Programming was around for quite some time (XP is here
since 2000), but I have a feeling that recently I am hearing more about this
then I heard before.
Interestingly I also have an impression that when hear about
100% pairing, it would normally be either involve an IT consultancy practising
it or people who in the past used to work for one of IT consultancies.
I suspect there is a reason for IT consultancies to practise
pair programming – you can charge for two people doing the same work (explaining
that “it improves the quality”) and it would allow them to send to a customer
an inexperienced developers paired with one that have experience while charging
if they both were experienced.
I can also understand why managers might like it – it allows
them to see developers as an exchangeable “resource”, eliminating a “bus
factor” while at the same time ensuring that the developers police each other
in terms of actually “doing the job” and having even to inform each other when
they go for a pee.
What I don’t understand is why some developers support this?
Do people really want to be sitting next to someone else at
the same desk day in and day out instead of having their own place in the
office, which they can personalise the way they like (pictures of kittens, Star
Wars poster or whatever else their personal kink would be). Don’t they want a
place where they don’t have to suffer because someone else has poor hygiene
habits?
Do they want to be able to use any IDE they fancy and setup
their machine to whatever weird configuration they favour, or do they prefer
this decided by a “committee” and they been forced to follow rules?
Do they like to be “one of the pair” instead of “that guy
who did that cool thing”? Are they feeling too insecure in their professional
abilities that they are afraid to work on their own?
How do they see themselves in 10 years time? Still be a
faceless member of a “Team” members of which are not even trusted to work on
their own at their own desks?
Talking about personal interest as far as a developer
concern I can see only disadvantages:
-
It is more difficult to demonstrate your own
abilities and worth to the management if they never see your name attached
to anything unless it is with other person, hence less chances of career
advancement based on your own abilities as a programmer.
-
The management sees you as replaceable (as far
as they concern there are always other people available to do your job,
everybody you are pairing with are good enough candidates).
-
You have less freedom over what you do and how
you do it – you have to explain every step to your pair and you have to
coordinate with others all your activities
-
You have less comfort in your workplace, as you
have to share space in front of the screen with someone else.
Other people's blog posts on Pair Programming:
I'm a Pair-programming Skeptic
Why I Don't Like Pair Programming (and Why I Left Pivotal)
https://www.infoq.com/articles/pair-programming-no-panacea
Posted copy on Dzone: https://dzone.com/articles/pair-programming-whats-in-it-for-me
I'm a Pair-programming Skeptic
Why I Don't Like Pair Programming (and Why I Left Pivotal)
https://www.infoq.com/articles/pair-programming-no-panacea
Posted copy on Dzone: https://dzone.com/articles/pair-programming-whats-in-it-for-me
Subscribe to:
Posts (Atom)