Signs that you’re a bad programmer

Software Engineering Tips shares some tips on how to figure out if you are a bad programmer, and how to remedy that.

Signs that you’re a bad programmer

  1. Inability to reason about code
  2. Poor understanding of the language’s programming model
  3. Deficient research skills / Chronically poor knowledge of the platform’s features
  4. Inability to comprehend pointers
  5. Difficulty seeing through recursion
  6. Distrust of code

If you are not a bad programmer, check if you are mediocre one.

Signs that you are a mediocre programmer

  1. Inability to think in sets
  2. Lack of critical thinking
  3. Pinball Programming
  4. Unfamiliar with the principles of security
  5. Code is a mess

And, finally, here are some signs that you shouldn’t be a programmer.

Signs that you shouldn’t be a programmer

  1. Inability to determine the order of program execution
  2. Insufficient ability to think abstractly
  3. Collyer Brothers syndrome
  4. Dysfunctional sense of causality
  5. Indifference to outcomes

The article also suggests some alternative career paths for you.

The True Reason Behind The 40-Hour Work Week & Why We Are Economic Slaves

The True Reason Behind The 40-Hour Work Week & Why We Are Economic Slaves” doesn’t really say anything new, but it explains things nice and simple.

We automatically accept a 40-hour workweek with meager hourly pay as normal, even though many work overtime and still struggle to survive. There are also those who make enough to live comfortably but are unable to request less hours—you either work 40 hours a week, or you don’t get to work at all. We submit when told what to wear, when we have to arrive and depart, when we’re allowed to eat, and even when we’re allowed to use the restroom. How is it we have come to allow this?

The 40-hour-work week came about during the Industrial Revolution in Britain when at one point workers were putting in 10 to 16 hour days and began to protest. Working situations for Americans began to worsen as well, and by 1836, labor movement publications were also calling for a 40-hour workweek. Citizens in both situations were so overworked, an eight-hour day was easily accepted. This system is unnecessary now, if it ever was, but we still accept it due to the effects of our capitalist society.

It goes over the relationship of inflation, debt and consumerism with a few historical references.  Good reading for anybody wondering why the paycheck-to-paycheck life cycle is difficult to change, no matter what’s the size of the paycheck.

Power in a distributed organization vs traditional

Chris Hardie, who works for Automattic, shares his observations on where the power in a distributed organization comes from, versus the traditional one.

In an office setting, I see power and influence gather around…

  • The person with the newest, coolest and/or most expensive clothing
  • The person with the larger corner office
  • The person with the most assistants
  • The person with the most impressive sounding title
  • The person with the closest parking space
  • The oldest, richest, whitest males
  • The person who’s allowed to create or interrupt meetings
  • The person with the most impressive social and public-speaking skills
  • The person who uses their power to get what they want

In a distributed organization, I see power and influence gather around…

  • The person who produces output and solutions that exceed expectations
  • The person who can connect deeply with colleagues over a distance
  • The person who can effectively and concisely articulate their own views and ideas
  • The person who helps their coworkers be the best versions of themselves
  • The person generous with their understanding of how to navigate the organization’s processes and culture
  • The person who can give voice to unrecognized or unspoken truths
  • The person who learns fastest from their mistakes
  • The person who uses their power to empower others

It’s of course not fair to generalize this way. There are healthy traditional organizations where appearances are not necessarily the basis for power. There are probably unhealthy distributed organizations where power centers around the appearance of lots of activity that produces few good outcomes. But my experience so far is that a distributed organizational structure inherently facilitates an experience of power, empowerment and leadership that is better for the people in it, and for the work they are doing together.

I don’t have much experience working for a distributed organization, but judging by many Open Source projects, which are, in essence, distributed organizations, I’m inclined to agree with the above observations.  I wouldn’t be able to put in words so well though.

Is It Worth the Time?

I’ve seen this chart before, but completely forgot where it was from.  Tried to find it a couple of times in a hurry of a conversation, but couldn’t.  Thanks to this SysAdvent blog post, I now have it permanently engraved into the archives of my blog.

xkcd figured out how long can you work on making a routine task more efficient before you’re spending more time than you save.  The crossing of how much time you shave off and how often you do the task gets progressively less obvious when move from the top left corner of this char to the bottom right corner.

What does Operations *do*?

SysAdvent runs a blog post about Operations (in IT sense of a word), explaining what the department (hopefully it’s a department and not a single guy who doesn’t remember the meaning of the word “sleep”) does, and how the job complexity silently escalates with time.

An operations team, almost by definition, focuses on the steady-state “run” of whatever that team is responsible for … well, operating. This could be an electrical plant, an HR department, or an IT operations team; anything which needs to function day-in and day-out, reliably and without fuss. Those things the rest of us assume “just work”.

But just because we don’t notice doesn’t mean there isn’t anything happening. Much like an iceberg, where 90% of its mass sits below the waterline, nobody outside the team is aware of what the team actually does in order to make sure everything “just works”.

Anybody who’s been involved in Operations, at some point goes through this bit:

We can see how Oscar’s responsibilities grew over just two years. At first, it was just 6–8 laptops, office wifi, and a third-party office solution. Then it’s a cobbled-together server. Then development environments. Within a year, it’s 20 laptops, two application environments in the cloud, monitoring, alerting, and backups. After another 12 months, it’s a dozen third-party services, 40 laptops, 2 team members, offboarding processes, and monthly security audits.

Over beers one evening, Oscar makes the comment to a teammate that even he didn’t understand just how profoundly the company depended on the operations team; how much impact his work had on everyone else’s ability to do their jobs.

This blog post actually goes well with the one I am planning to write shortly about software features being like babies.  Stay tuned.

Two years at Qobo

Today marks the completion of my second year at Qobo Ltd.  The first year was quite a ride.  But the second one was even wilder.  As always, it’s difficult (and lengthy) to mention everything that happened.  A lot of that stuff is under the non-disclosure agreement (NDA) terms too.  But here are a few generic highlights:

  • Vision and strategy – most of my first year has been spent in putting out fires, fixing things big and small, left, right, and center.  The technology boost was necessary across the board, so it didn’t leave much time for the vision and strategy.  I feel that we’ve made a huge progress in this area in the last 12 month.  We have a clear vision.  We have all the stakeholders agreeing on all key elements.  We have worked out a strategy on how to move forward.  And we’ve started implementing this strategy (hey, Qobrix!).  In terms of achievements, I think this was the most important area and I am pretty happy with how things are shaping up.
  • Team changes – much like in the first year, we had quite a few changes in the team.  Some of them were unfortunate, others not so much.  The team is still smaller than what we want and need, but I think we are making progress here.  If our World Domination plans will work out to even some degree, we’ll be in a much better place very soon.
  • Technology focus – we’ve continued with our goal of doing fewer things but doing them better.  Our expertise in WordPress, CakePHP and SugarCRM grew a lot.  We’ve signed and deployed a variety of projects, which resulted in more in-depth knowledge, more networking with people around each technology, more tools and practices that we can reuse in our future work.
  • Open Source Softwareour GitHub profile is growing, with more repositories, pull requests, releases, features, and bug fixes.  We’ve also contributed to a variety of Open Source projects.  Our involvement with Open Source Software will continue to grow – that’s one of those things that I am absolutely sure about.
  • Hosting, continuous integration and delivery (CI/CD), and quality assurance – again, the trend continued this year.  We are using (and understanding) more of the cloud infrastructure in general and Amazon AWS in particular.  We have a much better Zabbix setup.  And our love and appreciation of Ansible grows steeply. Let’s Encrypt is in use, but we’ll grow it to cover all our projects soon.  We are also experimenting with a variety of quality assurance tools.  We are using TravisCI for most of our Open Source work.  And we are on the brink of using recently announced BitBucket Pipelines for our private repositories (sorry Jenkins, we’ve tried you, but … not yet).  We’ve also jumped into ChatOps world with HipChat and its integrations, to the point that it’s difficult to imagine how could we have worked without it just a few month ago.  Codecov.io has also proved to be useful.
  • Projects, projects, projects – much like the previous year, we’ve completed a whole lot of projects (see some of our clients).  Some were simple and straightforward.  Others were complicated and challenging. And we have more of these in the pipelines.  Overall, we’ve learned how to do more with less.  Our productivity, technical expertise, and confidence grows day-to-day.  I hope we keep it up for years to come.
  • Website – one thing that we wanted to do for ages is to update our website.  Which we did, despite all the crazy things going on.  It’s not a complete redesign, but it’s a nice refreshment.  And we’ve also got our blog section, which I promised you last year.  All we need to do now is to use it more. ;)

There are a couple of major updates coming soon, but I am not at liberty to share them right now.  But they are very, very exciting – that’s all I can say today.  Keep an eye our blog – we’ll be definitely sharing.

As I said, it was quite an intense year, with lots of things going on everywhere.  There were tough times, and there were easy times.  There were challenges and there were accomplishments.  There were successes, and there were mistakes and failures.  But I wouldn’t have it any other way!

After two years, I am still excited about this company and about my job here.  (Which, looking at my career so far, is not something that happens often.)  I hope the next year will continue the adventure and by the end of it I’ll be able to proudly show you a few more things.

 

101 Most Common Interview Questions with Pass or Fail Answers

Following the recent post “10 Favorite Job Interview Questions for Linux System Administrators“, here is a more generic, but a much more comprehensive resource – “101 Most Common Interview Questions with Pass or Fail Answers“.  It’s not as technical, but it provides a good summary of common interview questions, from the generic ones like “Why do you want to leave your current company”, through brainteasers like “How many gas stations are there in the United States?”, to stress and communication ones like “What did you do when you had a boss you didn’t get along with?”.  The good thing is that you’ll find not only the questions, but also the suggestions on how to answer them.

Altogether, it’s a great resource to go through before your next interview.  Most of these questions are very common, no matter which position you are applying to.

What is a Senior Developer?

I’ve been hiring, firing, and working with developers of all sorts for the last couple of decades.  In those years, I realized that each developer is very unique – their strong and weak sides, knowledge gaps, working rhythm, social interaction, communication abilities, etc.  But regardless of how unique each developer is, it is often useful to group them into expertise levels, like junior and senior.  Companies do that for a variety of reasons – billing rates, expectations, training required, responsibility, etc.

And this is where things get tricky.  One needs a good definition of what a senior developer is (other definitions can be derived from this one one too).  There is no standard definition that everybody agrees upon, so each one has their own.

I mostly consider a senior developer to be self-sufficient and self-motivated.  It’s somebody who has the expertise to solve, or find ways of solving any kind of technical problems.  It’s also someone who can see the company’s business needs and issues, and can find work to do, even if nothing has been recently assigned to him.  A senior developer would also provide guidance and mentorship to the junior teammates. I’ve also came to believe that people with the real expertise have no problem discussing complex technical issues in simple terms, but that’s just a side note.

Anyway, recently, I came across this very short blog post, which sent me a spree of pages, charts, and discussions:

Because of this “What is a senior developer?” conversation on Reddit, I am reminded of the Construx Professional Development Ladders, as mentioned to me long ago by Alejandro Garcia Fernandez. Here is a sample ladder for developers.

The original article for the Reddit discussion – “The Conjoined Triangles of Senior-Level Development” is absolutely brilliant.  In the beginning it provides a chart of the conjoined triangles of senior-level development, which reflects my definition and understanding:

conjoined

But it doesn’t stop there. It dives deeper into the problem, and, eventually features this Venn diagram:

venn

.. and more.  By now, I’ve read the article three times, but I keep coming back to it – it just makes me think and rethink over and over again.  Once it settles in my head a bit, I’ll look deeper into the Professional Development Ladder and it’s example application to the senior developer.

Overall, this is a very thought provoking bunch of links.