Monthly Archives: December 2018

Ruby exceptions are 4400 times faster than ActiveRecord::Base#create

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

How slow are Ruby exceptions as compared to other frequent actions we may be doing in Rails apps. Like for example, as compared to ActiveRecord::Base#create

Big thanks to Robert Pankowecki who created the original gist and to Piotr Szotkowski who provided even more data. The gist was originally created as part of our Fearless Refactoring: Rails Controllers book where Ruby exceptions are suggested as one of the possible techniques of the controller communication with service objects.

 require 'active_record' require 'benchmark/ips'  ActiveRecord::Base.logger = nil ActiveRecord::Base.establish_connection adapter:  'postgresql',                                         database: 'whatevers'  Whatever =  Benchmark.ips do |bench|'SQL query')      { Whatever.create(text: 'meh') }'exception hit')  { raise rescue nil }'exception miss') { raise if false }! end 

Then we can run it with:

ruby -v bench.rb

with results like this:

ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux] Warming up --------------------------------------            SQL query    18.000  i/100ms        exception hit    57.640k i/100ms       exception miss   269.546k i/100ms Calculating -------------------------------------            SQL query    182.124  (±15.9%) i/s -    882.000  in   5.003193s        exception hit    808.613k (± 4.8%) i/s -      4.035M in   5.004163s       exception miss     10.129M (± 3.2%) i/s -     50.675M in   5.007747s  Comparison:       exception miss: 10129279.5 i/s        exception hit:   808613.1 i/s - 12.53x slower            SQL query:      182.1 i/s - 55617.43x slower

which means that for this configuration, the exceptions are 4438 times faster than AR::Base#create.

Rails and adapter objects: different implementations in production and tests

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

If you work with service objects in Rails apps, very quickly you need to have the dependency being passed to the service object constructor. Which usually means, that the Rails controller needs to do it. This blogpost describes how to have a different implementation being passed in the production environment and an in-memory one in the tests.

There are several possible solutions, but one could be closer to the hearts of many Rails developers. Let’s just use the built-in Rails environments and configure them appropriately:

$ ag foo_adapter config/environments/ config/environments/development.rb 187:  config.foo_adapter     =  config/environments/production.rb 164:  config.foo_adapter     =  config/environments/test.rb 184:  config.foo_adapter     = 

As you see, we have the same implementations in the production/dev environments, but a different one in the tests. The tests use an in-memory implementation which probably doesn’t really send the requests to the Foo API.

In the Rails controller, you can then initialize the service object with:

 def create   #... end 

while in the service object you stay unaware of the difference:

 class RegisterNewUser   def initialize(foo_adapter)     @foo_adapter = foo_adapter   end end 

The typical Ruby bugs with changing the last line in a method

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

In Ruby, we don’t have to type return at the end of the method. As many other things in our favourite language, this is implicit, not explicit. The value of the last line in a method is also automatically the value of the whole method. Which is a good thing as it helps making the code less verbose and more poem-like. But it also has some dangers.

Only this year, we’ve had two different situations where experienced developers introduced bugs into a system.

The first story started when business wanted us to remove one existing feature from the application. This feature was something about analytics code in the view. The intention was to no longer track something.

There was something like this in the code.

 def analytics_code   setup_which_is_meant_to_stay_here   track_something end 

The developer looked at the code. It was quite clear that the last call should be removed, so he did that.

 def analytics_code   setup_which_is_meant_to_stay_here end 

Apparently, it was crucial that the value returned by this method was actually used in the view.

= tracker.analytics_code 

It went through several layers, so it wasn’t that easy to spot. The result?

The result was actually very bad – the setup_which_is_meant_to_stay_here call returned a hash with a lot of information about internals of our system. And it all went to the front page of one of the systems. Which we learnt only a few hours later.

The second story happened just recently, in my project. There’s a place in the UI (react+redux), where we register new customers. Submitting the form creates an ajax request, which goes to the backend, which then calls a special microservice (bounded context) and then we get the response back to let the UI know that all is good with some additional information to display. It was all good and working.

But then, we’ve had a need to extend the existing backend code with publishing an event. The code was a typical service object in a Rails app:

 class RegisterNewCustomer   def call     customer =   end end 

After extending the service object, it looked like this:

 class RegisterNewCustomer   def call     customer =     event_bus.publish(customer_registered)   end end 

The thing is, this service object was used from a controller, like this:

 def create   customer =   render json: customer end 

We haven’t noticed the problem at first. The visible difference was that the UI now showed a failure message, but it was actually adding the customer to the system!

And the exception under the hood was something about IOError, which didn’t help in debugging it.

As you see, two different stories, but the same problem – changing the last line of a method. Be careful with that 🙂

Overcommunication is required for async/remote work

At Arkency we’re working remotely. Being able to work remotely is just a side-effect of working asynchronously.

Let’s talk about what it means in practice.

Async means working at the time you choose and not the time, the rest of the team insists on.

Async means not being blocked on work of other people. It also means not blocking other people on your work.

Remote work doesn’t need to be async. You can still have rules about certain time of working. In that case, blocking on each other is less of a big deal. You can always interrupt others to remove blockades. As in the office.

Async is where the fun begins. Async is where productivity begins.

I sometimes hear people saying – “working remotely is not for me”. I prefer to use other words.

Async work, like remote work is a skill. You can choose to learn but you may be fine without learning it. You don’t need to have a special talent to work async/remotely. It’s about skills you can practice, it’s up to you. You control it.

Async work is actually a set of skills. One of the most important skills is overcommunication.

It’s hard to work async without overcommunication.

Actually, overcommunication is also a big term and not very precise.

At the very minimum, I want to overcommunicate to the rest of the team what I’m working on. It should be super-easy for others in the team to say – Andrzej is working on feature X.

I can do it in several ways:

  • assign myself to the ticket on the (single) backlog
  • keep pushing commits, so others can see which code I’m changing and what are the commits description. it’s good when the commit notifications land in the project slack channel
  • mentioning on slack: “just to overcommunicate – I’m working on this tenant filtering bug”

That was the minimum.

What’s close to the maximum? When you let others to help you if your solution is wrong.

You can do it only if you present not only what you work on, but also how you’re planning to work on it. Additionally, communicating along the way, how it goes.

How can I do it?

  • when I assign myself to the ticket, I can explain how I understand the scope of the task (on slack)
  • I can present a possible todo list for the task. It can be on the backlog itself (like trello) or just a snippet on slack
  • I can provide an estimate
  • I can paste some of my code changes along the way in the slack channel
  • I can communicate all I found in the existing code which is interesting in any way – existing technical debt
  • create new tickets for all functional bugs I find
  • documenting technical components which I’m touching now
  • the scout rule is also overcommunication – fix something here, if it was easy and fast to do it. keep improving the existing area
  • blog about your solution (without leaking client sensitive info, of course)

Working async doesn’t mean we force ourselves to work at different times. It’s almost always the case, that someone else is working at the same time. My team members can see my messages. They can read it but don’t have to. They can choose not to reply. They can choose to reply now or later. It’s up to them.

Some chances are that if I’m doing something stupid (and I often do), then can quickly tell me. If I’m going over the scope of the ticket they can correct me.

In our case, it’s not only project members who can help me. Also people from other teams stay interested in what is going on. They become familiar with the project (good for possible future rotations!). They can help me too. They can also learn from me, if I did something nice.

Overcommunication is like the best parts of live pairing, without the uncomfortable ones. It’s like being surrounded by friends who want to help me, if only I give them the chance to help me.

I choose to give them the chance.

Happy overcommunicating!

We wrote a book called “Async/Remote” where you can find more about the required skills for async work, not only over-communication. Those are things like “1-size stories”, “single backlog”, “async standups”.

The book is now part of the “Smart Income for Developers” bundle. It’s a good deal. Go check it out, it’s only valid this week.

Running bash command from Ruby (with your bash_profile)

Whenever I try to automate some of my daily tasks, I end up with a mix of Ruby and Bash scripts. This is the time when I look up to the differences between system, exec, %x, backticks and others.

However, there’s additional thing with actually executing a bash script not just shell script.

Yesterday I’ve been optimizing my blogging flow. One part of it is to open my favourite editor with the current draft file.

Until yesterday I did it manually. I’ve had this in my bash_profile:

alias ia="open $1 -a /Applications/iA/ Writer" 

so just typing ia content/posts/ was opening the editor.

Now, I have a script which not only generates the draft file, but also git pushes it, opens the browser to preview it and opens the editor.

  def call     create_local_markdown_file_based_on_template     git_add_commit_push     open_browser_with_production_url     open_draft_in_editor   end 

See my previous blogpost to read more about this specific Ruby service object

The thing is, if you just use system it’s not enough. You need to invoke bash in a special mode -ilc to actually get the bash_profile loaded. Otherwise, the ia alias is not recognized.

So, I ended up with this:

  def open_draft_in_editor     system("bash", "-lic", "ia #{path}")   end 

Which works great so far. It helped me speeding up my blogging process and hopefully will result in more blogposts 😉

Happy blogging!

BTW, if you want to improve your blogging skils, my “Blogging for Busy Programmers” book is now part (for a limited time) of the Smart Income For Developers bundle. Check it out!

The esthetics of a Ruby service object

A service object in Ruby has some typical elements. There are some minor difference which I noted in the way people implement them. Let’s look at one example.

This example may be a bit unusual, as it doesn’t come from a Rails codebase. The service object actually comes from the engine of this very own blog. The blog is nanoc-based and the service object is used to locally generate a new draft of a blogpost.

You can read the first part of the story in the blogpost where I talked how this service object was extracted from a previous script.

The final result was the following:

 class CreateNewPostFromTemplate    def initialize(title, date)     @title = title     @date  = date   end    def call     unless File.exist?(path), 'w') { |f| f.write(template(@title, @date)) }       puts "Created post: #{path}"     else       puts "Post already exists: #{path}"       exit 1     end      puts "URL: #{likely_url_on_production}"   end end 

Today, I was trying to optimize and automate my blogging flow. This involved:

  • managing the typical git commands (add/commit/push)
  • opening the draft in the browser
  • opening the editor of my choice (iaWriter)

The code ended up looking like this:

class PublishNewDraftFromAndrzejTemplate    def initialize(title, date)     @title = title     @date  = date   end    def call     create_local_markdown_file_based_on_template     git_add_commit_push     open_browser_with_production_url     open_draft_in_browser   end    ... end 

When I tweeted it (just the call method), I’ve got one interesting reply from my friend who is not working with Ruby:

@andrzejkrzywda this may actually convince me to use #ruby….

— Pawel Klimczyk (@pwlklm) October 23, 2016

followed by this:

@psmyrdek @andrzejkrzywda not lines, rather the pure simplicity in code. This awesome.

— Pawel Klimczyk (@pwlklm) October 23, 2016

which got me thinking and inspired to write this blogpost (thanks Paweł!).

   def call     create_local_markdown_file_based_on_template     git_add_commit_push     open_browser_with_production_url     open_draft_in_browser   end 

What we see here, is a typical run/execute/call method (I’ve settled with “call”) which orchestrates other parts. The naming is a bit verbose but also quite explicit in describing what it does.

There’s something Ruby-specific which makes the code appealing to certain developers. This was probably the part which brought me to Ruby back in 2004 (and I still didn’t find a programming language which would be more esthetically appealing to me than Ruby!).

The lack of braces is one thing.

Then there’s the dynamic typing, resulting in no type declaration. Less verbose thanks to that.

There’s also a design choice here – there’s lack of params being passed. The “call” method doesn’t take anything, nor the other methods.

However, in fact, they do use some input data, but those 2 variables are set in the constructor method. This means that we can access them via “@title” and “@date” instance variables.

There are additional 7 private methods here, which are using the instance variables.

The topic of service objects in Rails apps was so fascinating to me that I wrote a whole book about it. One realisation I’ve had over my time spent on service objects is their connection to functions and to functional programming. Some people call them function objects or commands. My architectural journey led me to discover the beauty of Domain-Driven Development and CQRS (Command Query Responsibility Segregation).

At some point, all those pieces started to fit together. I’m now looking at code in a more functional way. What I was doing with my “Rails Refactoring” actions was actually about localizing the places where data gets mutated.

In fact, my current Rails/DDD teaching how to build Rails apps feels almost like Functional Programming.

So, the question appears – is this service object functional?

I’m not aware of all FP techniques, but being explicit with input/output of each function is one of the main rules, as I understand. Which means, that the 8 methods of my service object are not functional at all.

(the part of this object which mutates the whole world around – file system, git repo, operating system – is also not helping in calling it functional).

But let’s focus on the input arguments part. What if we explicitly add them?

   def call(title, date)     create_local_markdown_file_based_on_template(title, date)     git_add_commit_push(title, date)     open_browser_with_production_url(title, date)     open_draft_in_browser(title, date)   end 

Given that this post is about esthethics and it’s always a subject to personal opinion – I’d say it’s worse now. It’s more verbose, it’s even too explicit.

But there’s one part which makes this new code better. As a big refactoring fan, I can tell that when each method is explicit about the input it needs, the code is much more friendly towards extracting new classes and methods.

In this specific situation, the estethics won over the being refactoring-friendly 🙂

What’s your take on the esthetics here?

Developers as DDD bounded contexts representatives

Recently, I’ve been preparing to my webinar about introducing DDD to existing projects/teams.

One DDD part which is not always easy to explain is actually the main strategic pattern – bounded contexts. For the webinar purpose I came up with the idea of showing that in our programming teams we also have bounded contexts. What’s better, most of us, represent different bounded contexts.

In this blogpost I’d like to highlight some of such contexts.

The thing I’d like you to focus on is that the different types of developers – they all use different vocabulary when they play different roles. It’s worth noting it just for the purpose of a successful communication but also to learn that it’s the main point of DDD – find the domain language.

Performance oriented developer

  • “we should have written it in SQL”
  • “there’s nothing faster than reading from a file”
  • loves performance benchmarks
  • favourite words: cache, traffic, rpm (requests per minute)


  • excited about new frameworks
  • loves having many buzzwords in the resume
  • believes in the current The Framework Way
  • honours only developers who created frameworks
  • silently dreams about writing own framework
  • always up to date with the new framework of the week
  • great for writing prototypes


  • can’t sleep if someone wrote production code without tests first
  • when reviews code of others, starts with tests
  • with all new features thinks “how am I going to test it?”
  • great at refactoring critical pieces of code
  • makes sure about test coverage
  • excited about mutation testing

Sad FP programmer

  • super intelligent
  • can’t accept that some people see the world as mutable
  • modeling business means writing math equations
  • is sad, because can’t write code in the purest FP language
  • great at dealing with concurrency

Over-excited agiler

  • open-space fan
  • loves when people talk to each other
  • loves post-it notes on the wall
  • loves moving post-it notes between columns
  • generally loves post-it notes


  • the first one to establish a “code style guide” in the team
  • can argue about tabs/spaces for ages
  • good at documenting
  • will install all the possible code metrics tools
  • is happy when the build fails because of his post-push lint rules


  • with each feature thinks how much money it is going to bring
  • did calculations and know how much each line of code is worth
  • able to introduce a hack just to have the feature faster on production “making money”
    • then forgets about removing the hack
  • the best friend of product owners / customers
  • instead of writing tests, prefers to write bank account monitoring script – alerting when it’s balance is increasing slower
  • never a passionate of some specific tool – whatever gets the job done
  • thinks in budget terms


There’s definitely more such types/contexts. If you can name some – feel free to do it in the comments!

Please note, that each of us can play any of the roles at any time. However, sometimes some roles are more natural for each of us.

Note the language that we’re using. Even though we can have some fun describing the personas, all the contexts are important at specific times.

What contexts do we see here?

  • Performance
  • Technology/Tools
  • Tests / Refactoring / Regressions
  • Concurrency / Math / Proofs
  • Communication
  • Documentation / Standards
  • Budget / Finances / Accounting

This is all for our internal needs – to safely/efficiently deliver software.

Now look similarly at the actual project you’re working on. What subdomains do you see?

If you’re working on some kind of e-commerce, you’ll probably see:

  • Inventory
  • Catalog
  • Ordering
  • Accounting
  • Invoicing
  • Reports
  • Pricing
  • Promotions

and many others. It’s not uncommon to see ~30 potential bounded contexts.

Are they clearly represented in your system?

Each of them deserve a dedicated module. It’s truly bounded if they don’t talk to each other directly. They either communicate with events or there’s a layer above (app layer) which orchestrates them. Each of them should have a separate storage (conceptually) and never ever look at each other storage directly.

When I first encountered DDD – this all was a mystery to me. How to actually achieve this? Now, after seeing this happen in our projects it all seems much simpler.

Each context is either a separate module/directory in the repo or it’s a separare microservice/repository.

When I work on Accounting features, I’m not bothered by the concepts of other contexts. I’m only surrounded by things like accounts, revenues, profits. This makes me much easier “to get into the zone”.

Heck, thanks to the CQRS (I consider this to be part of the bigger DDD family) techniques, I don’t need to bother too much about how it displays on the UI. The “read” code is also separated.

Pssssst, if you’re interested in applying DDD in your Rails projects, consider coming for 2 days to Wrocław, Poland and attend our Rails DDD workshops. The next edition is 24-25 November, 2016.

This is how the first 2 hours of the workshops look like in the first edition – a heaven for the agilers – post-it notes everywhere 😉 It’s a technique called Event Storming – we visualize a system with events/commands/aggregates – each having a different color of a post-it note.

Our #Rails #DDD Workshop is happening right now!

— Arkency (@arkency) September 19, 2016

Hourly Billing is Nuts

When it comes to my salary, I am an ordinary guy who earns $ X per hour. I’ve been working this way since I joined Arkency, and I never thought much about it. I’ve been happy that if I need vacations or break, I can just take them (properly communicating it with the clients, of course) without much hassle. When I feel great, and I am inspired to work and work and work, I can just log more hours without thinking much about it as well. Just like monthly salary, hourly salary is a safe way to live. But is it the most rewarding way to live?

Hourly Billing is Nuts challenged my perception that hourly billing is the best way possible. I started to notice the bad parts as well, not only the good ones. I don’t agree completely with some parts of the book, but it got me thinking.

Hourly Billing is Nuts

I won’t summarize the book here because it’s better if you just read it yourself. So just a small challenge. At some point, you started working as a programmer with skills X and let’s say your current salary reflects that (no matter if you are an employee or freelancer). You read tons of books, invest in your skills, gain lots of experience and reach level 2X. How do you prove that you should be paid 2X now? Not to your boss but your customer… How? How can they see that you are worth twice the salary? As you can imagine, it’s problematic…

  • You could be working on features twice as fast, but you are not working on the same features, so it’s not easy to prove it.
  • It gets even worse. If you spent say three years acquiring those skills and your customer spent three years expanding the business into more complex areas then they might perceive you as being on the same level. But that can be misleading because you are now working on twice as hard problems with your skills being twice as good as they used to be. That’s why things can look similar to what they were some time ago.
  • You could be working on features that bring 2x the money that previous features used to. That would be perfect. But the thing is… It does not always depend on developers what features we work on, how they are used by clients, what’s the conversion rate. And often the most beneficial features are implemented at the beginning of a project and adding every new cross/up-sell is harder and less rewarding.
  • Or it can be a combination of any of those in any way. 25% faster on 25% more sophisticated features worth 25% more money means you are 100% more valuable in this simplified way of thinking 🙂

So I’ve been thinking how value pricing (pay per feature) changes things here. And I came to the conclusion that the change is mostly about moving this risk (and potential reward related to it). What do I mean by that?

  • When billing hourly the risk for an agency is minimal, and most of it is on the side of the customer. If the estimations are incorrect (and they always are), and things take longer, it’s the customer who pays more. This can be mitigated some way (for example by “we won’t pay you for more than Z hours” rule) but if it is, you are already beyond hourly billing and taking some part of the risk on your side.

    On the other hand, when you are doing fixed price project the whole risk is on your side. When things take longer customers don’t care (unless deadlines apply). It’s your time and your cost only. So the risk shifted.

  • What if by being a better developer, using the proper technology you can do the project in half the time it would take other companies? In hourly billing model, the reward is received by the customer. You did things cheaper, and they still have the budget to pay you for other features that you could work on during that freed time.

    In fixed price environment the reward is yours. You get the same amount of money, and you can work (or not 🙂 ) on a different task/project in the freed time.

Of course, you might argue that when you get 2X better, you can charge 2X more per hour. I agree, assuming you know how to convince your (new or existing customers) that you are now two times better. This can be hard.

But is it hard in the value pricing model? Not really. You charge like you used to, and you implement things faster. You monetize the free time however you want. The price is not directly correlated to the time you spend on the feature but to the value, it brings to your customer.

And that’s only a fraction of my thoughts after reading Hourly Billing Is Nuts. For years I’ve been comfortable with my hourly billing model, and I never challenged it consciously. Now I started to consider pros and cons of both approaches actively and wonder which one I should use with which customers. And which let me easily charge more when I get better.

P.S. Hourly Billing is Nuts is available as part of our Smart Income for Developers bundle in all packages.

The freelancer in you that wants to be FREE

Do you sometimes as a developer/freelancer/company owner have the feeling that you are being used? Not adequately paid? Treated like a resource?

That considering all the effort, time, investment, the school you went through you should earn more and live a happier life?

How many things do you know and use in your daily job? Try to list all of them. Here is my list:

  • Ruby
  • Rails
  • SQL (with different flavors that you need to know)
  • DDD
  • Git
  • Devops (networking stack, investigating, handling fuckups)
  • HTML
  • CSS
  • JavaScript (old and new flavors + constantly evolving browsers API, and non-browser node.js API)
  • Webpack

And that’s not even everything. I bet the list for you is very similar in length (no matter what is your main programming language and whether you are frontend or backend dev).

You want things to

  • be done on your conditions, not theirs
  • better projects, better leads, better customers
  • select people, you work with, and to be able to do that
  • you need to have a better reach, reputation, and authority

You don’t want to stress over things every time.

Most of the people finish their job after 5, go home and don’t give a fuck. I’ve been learning every week since 8 years after I finished studying at the university. I bet you are as well crunching knowledge on a daily basis. Educating yourself and improving your skills.

With the impostor syndrome so prevailing in our industry we always feel behind, we need to know more and we spend so much time and money and energy reading and educating in the ever-changing landscape of technologies.

And what do we get for it? A-holes who tell us that our estimations are too big, managers who try to micro-manage.

The freelancer in you that wants to be FREE

In the meantime, other programmers earn 2-10x more, work with nice people, on nice projects, for companies that make money, can spend time with their family and have a much happier life.

What went wrong?

Let me tell you what usually goes wrong in a situation like this.

We invest 99% of our time in tech skills (do you remember the long list a moment ago) and 1% of our time in business/sales/soft skills. Boom!

Want a better life? You need to start attracting better clients into your company. Nicer people, happier people, successful people that will respect your authority. People who treat collaboration with you as an investment into their company, not as a cost.

How to do that? The Independent Consulting Manual will help you find answers.

The freelancer in you that wants to be FREE

It will teach you how to:

  • Better qualify your clients
  • Grow an audience using podcasts
  • Productize your consulting offerings
  • Say no to bad work
  • Properly structure your sales website
  • Write proposals using options
  • Multiply the value of your services
  • Establish your fool-proof positioning
  • Automate your sales pipeline
  • Transition to value-based fees
  • Plan actual minimal viable products
  • Send effective cold outreach emails
  • Use winning email & phone scripts
  • Faster fulfillment with processes
  • Cope with entrepreneurial stress
  • Start and run a professional Slack
  • Master consulting’s emotional game
  • Travel as a business owner
  • Use social media to get new clients
  • Maintain a healthy work/life balance
  • Run your business from anywhere
  • Effectively use facebook ads
  • Avoid late payments & get paid on time
  • Handle overdue invoices
  • Most importantly, you’ll learn how to make more money.

And when you balance your skills to 80% tech and 20% business you will be truly an independent, happy consultant.

This book will be available as part of our Smart Income for Developers Bundle next week.

To blog or to write code?

Four years ago when I started writing first posts on Arkency blog, I didn’t have many expectations. I knew I wanted to share my knowledge and thoughts. Not much beyond that.

My 1st blog post took me 8 hours to write. I was excited but at the same time, I felt incredibly ineffective. Like any other skill (testing, programming), writing takes the time to get better. And to be able to harvest the benefits from invested time.

I wish more people blog. Even in our company, not everyone is writing regularly. Why would I love to see more bloggers? There are hundreds, thousands of developers working every day on solving unique problems. Finding interesting solutions. And they are never shared. The world does not know.

I am inspired by the collaboration spirit of open source apps and libraries. So much time and effort saved because we can re-use existing solutions and we don’t need to re-implement databases for every new project. Blogging is for me part of the same movement but on a different level. On the level of knowledge. Having the tools is one thing. Knowing how to use them properly is another.

But when I was starting I didn’t know all those things. I just wanted to be like the best programmers that I know about. Fowler, Feathers, Martin, Katz and many others. They inspired me hundreds of times and challenged me to be a professional. So I started to blog. And then many things happened.

Other developers started to read us. There were CTOs of bigger and smaller startups among them. They respected our technical skills and wanted to hire us. Right now most leads who contact us regarding collaboration are technical. They are developers, engineers who already know what we do, how we do it and how we work. We don’t need to sell our expertise. This is a very comfortable situation to be in. We are vouched by people who are already in the client’s organization. We start our collaboration from an entirely different level of trust.

It’s easier for us to charge higher rates. Our expertise is provided for free to others (as blog posts and books). It can be verified. If potential customers don’t agree with some techniques, we can explain them. It doesn’t work so good with existing clients (rising rates in such situation is a hard process) but with new leads it does. The more knowledge we have written down, the easier we can present the broad range of problems that we already dealt with.

Recruitment got easier. People want to work with good developers. So when they perceive you as experts, they are more likely to apply to you. Blog posts are like a magnet. You can present yourself to the world.

We speak more at conferences. Who do you think is more likely to be invited as a speaker at a conference? An unknown person or a developer with 100 blog posts. Who do you think is more trustworthy to deliver valuable knowledge, in the eyes of conference organizers? And conferences give you exposure which gives you leads, candidates and more.

We got workshop materials 🙂 Right now we are preparing ourselves for our second Rails DDD workshop. I’ve been reviewing what I would like to discuss as part of every module. Many of these topics we’ve already written about on our blog. I could re-use those materials as a starting point and save time. Many of our posts were starting points for our books. In other words, it’s easier to sell knowledge that you already have written down.

We have an excellent way to share knowledge between our whole team. We have our internal saying “there is Arkency blog post for that”. We use it when someone asks a question, and the answer is a link to our post about this topic. Or when you google something and find our post as a first result 🙂

So far I wrote 70 blog posts. My boss is already at 150. But it started with the first one. Blogging for busy programmers, which is part of our bundle will help you start with it. It doesn’t matter if you want to charge more, sell products, recruit more people or find more clients. Your blog can be a potent tool for achieving those goals. But…

  • You don’t have time…
  • You think everything you would like to say is obvious
  • You believe no one will read you
  • You procrastinate
  • You don’t believe your blog post will be good enough

We admire blogging programmers for their knowledge, for how they share it. We would like to work with them and achieve same things they achieved. But all those limitations… Can we handle them somehow?

It is easier to blog once you realize you are playing a long-term game. One, two or five blog posts are valuable but they won’t change your life. Let me show you a few examples from own blog posts

We all want the benefits of blogging, but we don’t know how to overcome our limitations. And this is where “Blogging for busy programmers” will help you. To cut the scope, to promote, to worry less about haters, to ship it and to finally become a proud blogger helping people every day (even when you are not writing).

Available as part of our Smart Income For Developers Bundle in all three available packages.