Skip to main content

Studying and developing as software development professional

As everybody in software development knows, or should know, that studying and experimenting is something one must do to stay on top of the game. That said this time I'm writing about my experiences and ideas of studying. In this post I'll be covering different methods of studying and how I feel about them and what other types of resources are available.

Reading a book

Reading a book is probably the most traditional way of studying and I do read a few books every year. To me this is a way to learn theory and principles of something but usually little to nothing to do with the actual implementation. This type book I usually read in a week or two and I like these books when their length is reasonable somewhere between 50 and 250 pages.

Reading a book with exercises

These are very common type of books in software development. These usually cover some theory and the exercises bring a pragramatic approach with what one can learn a basic implementation. Some of these books are good if they have good examples but a great number of these type of books are way too long to keep me interested all the way to the end.

Attending a online course

I'm currently attending one, actually my first one. This course contains several video lectures per week split in to 2 to 10 minute pieces, quizzes after lessons and homework that's validated instantly.  To me this seems to be a great way to learn. Video lectures contains theory and implementation examples, quizzes are questions of the theory or implementation and homework is implementing and that gives a pragmatic approach to the topic. On the other side this type learning requires quite a lot of time per week.

Working through a tutorial

Tutorials are usually a good way to learn a basics of a framework or a language or howto use a tool. The hardest part is usually to find a good tutorial.

The internet

The internet is full of different resources to use. I follow several websites that collect news, tutorials and blog posts e.g. dzone and infoq. I also follow people and feeds on google+ and twitter and these are a great way for me to share interesting news and posts with others.

Conclusion

These were my thoughts about studying and developing myself. There are probably other ways of learning that I didn't cover here or haven't tried leave a comment if you have one in mind.
Labels:

Popular posts from this blog

Simple code: Naming things

There are two hard things in programming and naming is one them. If you don't believe me ask Martin Fowler https://www.martinfowler.com/bliki/TwoHardThings.html . In this post I'll be covering some general conventions for naming things to improve readability and understandabilty of the code. There are lots of things that need a name in programming. Starting from higher abstractions to lower we need to name a project, API or library, we probably need to name the source code repository, when we get to the code we need to name our modules or packages, we give names to classes, objects, interfaces and in those we name our functions or methods and within those we name our variables. Overall a lot of things to name. TLDR; Basic rule There's a single basic convention to follow to achiveve better, more descriptive naming of things. Give it a meaningful name i.e. don't use shorthands like gen or single letter variables like a, x, z instead tell what it represents, what it does...
Read more

Simple code: Version control commits

Currently the most popular version control system is git and I'll be writing this based on git and it's functionalities and capabilities. Git is often seen as a way to enable distributed programming i.e. multiple programmers can work on the same code repository quite easily without disturbing each others work (much). In addition to that just like other VCS's it's also a log of work but to my experience that part is often unfortunately neglected. What I will be focusing this time is the log part because I think it deserves more attention. Why to create a meaningful log? The git log should consist from small meaningful changesets where each commit addresses a single problem. By dividing the log to small commits it enables resilient way of working. Being resilient enables simple and fast procedures to rollbacks, reviews, tags, branching etc. Lets say that a developer is implementing a REST API. The API needs a web layer that receives the HTTP requests, it probably has some...
Read more

Simple code extra: Readability examples

Seven ways to write the same code snippet  Here are eight ways to write the exactly same code. Some are easier to read than others and all are a variation of a code I've seen in a real code base. My personal favorite is #7, what's yours?  #1 One liner DAO.filter { it.name == "foo" }.map { it.company }.toSet() #2 two lines, three operations DAO.filter { it.name == "foo" }   .map { it.company }.toSet() #3 Evaluation on it's own line DAO.filter {   it.name == "foo" }.map { it.company }.toSet() #4 Each operation and evaluation on their own lines DAO.filter {   it.name == "foo" }.map { it.company } .toSet() #5 All function calls and evaluation on their own lines DAO   .filter {     it.name == "foo"   }.map { it.company }   .toSet() #6 Everything on it's own line DAO   .filter {     it.name == "foo"   }   .map { it.company }   .toSet() #7 All function calls on their own lines DAO   .filter {  i...
Read more