How to increase a productivity as a software developer - part I, LiveCoding

in programming •  8 years ago  (edited)

I don't remember exactly how I found a LiveCoding, but I remember the impression which this website made on me. I started my adventure with programming in 2003[1]. Then I didn't even had an internet connection - really ;) I've got a book Symfonia C++ and old compiler - Borland 3.11.

borland

Back then I had a big problem every time I had encounter a bug. As a newbie I did't knew how to debug code in efficient way and my book - which was really great - couldn't help with that. But I didn't give up - fortunately :)

What is the secret to learn programming much easier? You need to find your mentor, but this is more difficult than it may sound. They not grows on trees... at least they not used to do that ;)

Introduction

You may heard about Twitch, right? It's weird platform, where you can watch as other people play games. Why people do that? Because they want to share an experience, they have a common gaming passion. I am not a player, but I am sure that this is very entertaining, but also in some way, very educational. It was a matter of time (and internet bandwidth ;)) before people figure out that this can be used also for different ... passions :)

"You are spending too much time in front of your computer" ~ Mom

There are places, where people fully understand why you are "wasting" your time writing some meaningless silly code, which "does nothing useful". In such places people help each other because they understand how important this is for you. One of those place is LiveCoding.tv. I could end this article here... because those people are the reason why I love this place :)

But we live in XXI century and people like to know what benefits they can have from everything. Ok, I can explain that for you :)

Debugging out loud

There is well known phenomenon in programmers world that you can find a solution for your really complicated problem simply by describing it out loud to someone.

There is a theory that because sometimes you do not even need an input from person who you speak to (person to speak), that you could also use a rubber duck for this.

Rubber_duck

As silly as it sounds, this is actually true. But believe me, real people are much smarter and give much better coding advises :) It is so amazing for me how easily I can find there so many people who are so able to help me.

Code Review and Quality

CodeReview

This is almost obvious, that when other people watch as you work, they can notice things which you've missed. The earlier they will tell you about your mistake, the less time you will waste for debugging later.

I have also noticed that when other people watch me working, I am trying to write better code, with more unittests, with better formatting and better documentation. All because I want to keep my viewers informed about what I am doing right now.

Feedback

FeedbackLoop

We are not perfect, our decisions can't be always correct. You can have a good idea, but brainstorming sessions with others improves it almost every time. You probably already know that, but did you realize that with such transparency your feedback loop will be shorter than ever?

Archive of your work

You can find this useful at some point, that you will have a complete archive of development process of your code. Don't get me wrong, this should not even try to replace a documentation of your project. Documentation should be brief and search-able with a single phrase. Right now I am not aware of software which can find a text in a audio and video.

Nevertheless, you will never be able to document your work and thoughts about it in more detailed way. Maybe you will not need it, because you remember everything, but probably in the future you will not have time to maintain all of your projects. Maybe at some point someone could want to continue with your project and develop it even further, and they will have and explanation of every decision which you made during development. Wouldn't it be awesome? :)

Proof of Effort and Proof of Work

Proof of Effort - Have you had this situation, when you did something meaningful, but you had a felling that no one really understood how much time and effort you had to sacrifice to end up with quality like that? Been there, done that. But is it their fault, that you suck in marketing? :) No, it isn't!

The truth is, that behind each great project there are countless hours of hard work, sweat and tears. When people see hard work, they really can appreciate it, but you have to give them a chance to spot it!

Proof of Work - there are employers out there which needs guys like you, but sometimes you are in different part of the world. In theory they can hire you for remote job, but there are so many problems with remote employees...

With LiveCoding your work can be transparent as hell, and you can very easily proof that:

  • you are hard worker and you are not afraid of being evaluated - sounds professional?
  • you are not "less available" then any other employee, in case if anyone would need your help
  • you work efficiently without any supervision
  • you are quite a nice guy and for sure there will not be any troubles with you ;)

... and much more!

"But wait... people will steal my project!!!"

No, they won't. Let's face it, probably you are not coding a project which dominate the world, and even if you are (and I hope you will!), you have to remember that: "Idea is 1% of success, 99% is execution"

And because people are smart and can calculate, even if they want to build something similar, that's more likely that they will choose to help, join you or they will just offer you a cooperation. But why is that so? Because you've already proven who you really are. Do you remember the poins which I mentioned earlier? Professionals love to work with hard workers!

"This is great idea, but my project is close source and I can't change that"

Ok, I understand. In that case you have limited options. For sure it is worth to mention, that you can still do livecoding, because there is a feature of private streams. This is a paid option, but personally I am not surprised by that. This is the same business model which Github used for so many years and is going to continue, and its proven that it's able to support open source movement and can secure the future of a company. I know about at least few guys on livecoding.tv which are using private streams as a tool for remote jobs :)

I know it works for me. Will it work for you?

I am developing my project - open source Price Comparison Engine - since 1st April. I recorded more than 150 hours of coding, with 7406 views, 116 followers and 20 stars on github - that's crazy! :)

Since I started using livecoding I've noticed that I can do more in less time in much better atmosphere. This motives me so well!
commits

Will it work for you? Don't know, but there is only one way to figure out...

This article was written during 5 hours of livecoding or rather liveblogging - :)

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

Me Too!!!

Steemit! I love this place! :)

My favorite debugging tool is printf.

This really begins to fail when doing massively parallel applications on numerous cores with main computations offloaded to GPUs.

Don't forget your -g debugging flag and another great too, addr2line.

And remember, gdb is your friend!

Personally I do not like to debug with printf's or gdb-like tools. The reason for that is you cannot easily skim data which are on stacktrace, you cannot so easily change those variables in runtime, and so many other things...

I find out, that people which debugs with prints in most cases use vim as a editor. Don't let me wrong, I also like vim, but it is only very powerful editor. IDE gives you in most cases much more... but you have to give up more RAM ;)

When you are developing on remote servers, you don't always have the luxury of the nice GUI of various IDEs. X forwarding over ssh sucks ...

For all my real debugging tools (whenever I am testing code on full-scale production on hundreds of cores and ten thousands of threads), I use PAPI hardware counters, but more importantly Score-P, which gives me a lot more detailed aggregate information on time spent in MPI communication, stack trace on a given thread, etc.

I should also add that I have to debug other people's code, so, in this case, gdb and addr2line are very useful, especially when I am not familiar with the codebase.

Debugging my own code is a nightmare. Debugging other's is hell.

Well done my friend :D

I can't stress how helpful a mentor is to kickstarting a development career.

I was lucky enough to have a friend that was willing to take me under his wing. We both had jobs at different companies, both underwhelmed by the tasks we were given, and both looking for a little more. We worked together for almost 5 years on nights and weekends because of this drive.

We would sit around and building things we thought were cool. Solve problems we felt hadn't been solved well enough. One of the two of us would have a hair brained idea and we would build into the wee hours of the morning. It was glorious.

I learned more from working closely with a mentor than I ever could have any other way. I really can see how live coding on LiveCoding.tv could accomplish this same thing. The motivation, the interactivity, and the sharing of knowledge.

Well said. For anyone really looking to up their development game, if you haven't been a mentor or mentee, I'd highly recommend it.

This is a really great article both for budding and experienced developers. I'm a junior software engineer/QA engineer currently at a startup with many bugs as the product was built very hastily.

All of our most complex problems are solved when we come together and discuss them either in pairs or in groups, even after we've individually spent days bashing our heads against the problem.

We pair program as often as possible as it not only helps us debug more easily, but create higher quality software right from the start. I never even thought about using twitch to basically "pair program" with people I've never even met before. That's a really great idea!

What you mentioned is a type of programming and its called extreme programming, but I think that you have to look on the whole Product-Lifecycle task to improve your productivity.

What I learned as a certified Tester is to review, review and review the product status in the whole product-lifecycle.

For further advises you can contact me.

Best Greets

agree!

boosting productivity is one of the most difficult tasks there is to programming, since learning new languages is easy when you have good logic, you really took on a very interesting topic, great job!

Tanks for this great post.
This would realy work great for mee.

-Kind Regards

i love this post, excelent!

This was a great read and some interesting tips. I am a "front end" guy myself, so I try to avoid the backend development and getting my hands dirty with code if I do not have to :P

Great article. Commenting to not forget to reread this great advice!

Thank you very much :)

A productivity trick that worked well for me lately: set a 1 hour timer.

I realized my coding days were already about sprints and chill out. The more I get into a project for a long time, the less time I spend in sprints.

So what I do now is to ask myself : "what important thing can I do in an hour?". If it's just a part of a feature, not releasable by itself, that's ok, provided I feel there's some kind of unity in it. When I've decided something, I don't start my timer just yet, but read codebase, think of an implementation path, wonder about side effects. And when I'm sure, I'll start the timer and go coding.

Sometime, it will takes less than an hour, sometime it'll take more. I try to stick to an hour but I don't make it a strict rule I should absolutely observe. But this feeling of constraint allows me to focus more, and not to feel guilty / in the urge when I'm between two sprints and I chat with colleagues.

Doing so, I've went for an average of 2 or 3 sprints a day to 4 or 5. That's a win.

I just checked recording from livecoding of you writing this article. Unfortunately it's really hard for me to listen to you.
That's mainly because you are making too many breaks during each sentence what makes it really hard to focus.

I'm not writing this as a hate post. I just want to point out what you can try to improve in the future.

Thank you for your feedback. That is true, I have to work on that. I hope, writing articles like that will help me improve my English and communication skills :)

  ·  8 years ago Reveal Comment