Evaluation of #hackership

Tweet

Hackerships experience has been amazing and  in every amazing experience one has also to evaluate things once it’s over.
The good thing about evaluation is to better  understand the processes in which you took part, to learn from them and also see how can they be improved, of course everything from a very personal experience, from a very personal point of view.

To keep it simple, I’ll just try to list all things learned and the suggestions I would have for future batches.

It is difficult to specify all the things learned since many times is just about clarifying concepts but let’s try to do the list, first of the technical stuff

1.- Test Driven Development, it was the first time that I’ve done TDD and really I’ve find out that is great, I don’t know if to do everything 100% TDD but for sure, for the start and everytime you want to implement a feature, TDD helps me to think about what the app should do and to write the code step by step

2.- RSPEC (unit tests and integration tests), I had used rspec, but normally for doing tests after having the code, which means that normally I didn’t go too deep into it because writing tests was kind of “optional”.

3.- Ruby & Rails (revised the basics,  basics of metaprogramming, learned about implementation of webservices via REST API). Ruby & Rails are endless so I cannot strictly say what I’ve learned, many things I had seen them but not remember them, other have been new, others I thought I understood them but it was not so quite so, so being able to do an app starting from scratch, to have had Q&A sessions has been just great to feel more confident.

4.- GIT (general overview of the usage of git) during the Rails Girls Summer of Code, we used quite a lot of GIT and since it was inside a big project I would say we did kind of a semi-advance use of it, but not really understanding all that was going on, so after hackership it has been more about understanding than seeing something new, which is cool!

5.- Javascript (js basics, interaction with rails and an overview of several frameworks), here is where I miss having more hackership time, I’ve done the very basics but not really got the feeling of JS

6.- Processing (Introductory session), finally seen how processing works after years of hearing about it 🙂

7.- Arduino (Introductory sessions), cool to play around, to see that I actually have no idea of how circuits work, and willing to spend more time on that, is there an spare life to borrow?

8.- The existence of Haskell, Scala .. coming to know things that I did not even know that existed is cool

9.- SCRUM methodology or at last some of the basics

10.- Written a post every single day, which is the first time I manage to do it
11.- Walk everyday 45 minutes
12.- Be on time

The last for things are not technical things but in the case of SCRUM I think is really important to get familiar with the way of doing, since it’s apply in many working environments, though SCRUM I guess is not one strict methodology but something that people tend to adapt to their needs or their particularities.

To write a post everyday during 6 weeks in my case means, that I’ve been highly motivated to be able to do so. I do like writing, I like it a lot but normally I don’t find the time, or how to write about something or…but when hackership started I decided that I wanted to do it. In the last years I’ve been more aware of the importance of story telling  but, except in a specific context, I had not manage to carry it out it a continuous way, hackership has motivate me enough as to be able to narrate the everyday life, for that I set a couple of rules to myself, one I would write without doing much revision of texts, not much thinking about it, just say it, another one was, it not just an exercise to let others know but also for me to revise things learned, thoughts had, references read, articles discovered, writing has been part of the hackerships flow.

Walking 45 minutes, everyday, was mainly a need, my body would not be able to survive without doing some exercise, feel some movement, see the daylight even the dark days, but of course is also a sign of motivation to do it before 10am, it has been nice to see Berlin during the morning, empty streets, full trams, bikes cycling in queue, discover new routes to places, get some fresh morning air.

And to be on time, well that has been quite a challenge, I’m normally the sort of person that arrives almost on time but not so much on time, except for key meetings, dates, etc. In my daily life, time is something flexible, more or less I try to be on time, but when doing things, is also important to finish the task you’re on, when meeting someone in the street is always important to stop and say hello properly, when you need to buy something is better now that later because who knows what can happen later, so yes normally for me time is flexible, a flexibility of 10-15min but during HS I’ve been almost British.

To that we have to add, other kind of things learned in workshops that are not specific but that help to understand the developers real environment, as the meeting of front-end and back-end, how to get unstuck, how to proceed with job interviews … probably more that I’ve now forgotten, but that have helped not to only learn about a specific language but how technology works (sometimes).

But even if everything has gone pretty well and I’ve enjoyed a lot, I do have things that I’ve missed and suggestions for future batches,

1.- Pair programming, I missed working on teams also because many of the tools learned make more sense when used in teams. Pair programming can be s good approach. This is something which I’ve had heard for a long time but also not really pay much attention to it, or let’s say not had the option of really doing it, this summer in the Rails Girls Summer of Code, we did pair programming and I really liked it, is a way to do many of the things that we say is good for learning but that then we don’t do.

For example, if you do a proposal of how to implement something you have to explain it, you have to be able to listen to improvements to the proposal or do something different that your pair proposes and makes more sense, you learn to make better questions, you have 4 eyes to check things, code or find out what was miss spelled, you learn to work in a team, so of course it can happen that you don’t like your pair, but as a whole I would say that pair programming is a better option for learning, can also mean to do some stuff on your own but knowing that your pair will check it, use it, etc.

2.- Working on open source projects, here I won’t be too objective, I am a real fan of free software, actually that is what got me into technology, so  to include as part of a learning process the knowledge of how to collaborate with others in already existing software, you have to read code, you have to ask good questions, you can contribute to a product that is for the benefit of a community and if your contribution is merged it feels cool!

So, I think is good for everyone,  to get more developers that can support free software tools and to take advantage of the great knowledge that is out there, so it would be the following thing to do after the “read fucking code”, which is possible because is open.

3.- Schedule workshops with a bit more margin. I think one feelings was that sometimes the workshops proposed were of great interest so you didn’t want to miss them, but at the same time the schedule change so much that it was difficult to organize your work, not sure how to improve it, but perhaps think in advance which workshops could be done earlier in the batch process, times …

4.- Have sessions in a “coderetreat” way of doing. The experience of participating in te coderetreat global day, has showed me that it is really a good way of learning or improving to code. Coderetreat is basically

• TDD over just one problem, Conway’s Game of Life,  the basic issue is to think how to approach a problem, not so much if you know a programming language or not (you can be a beginner and just help to think on the approach)
• Do pair programming and see and feel that there are a lot of different ways of doing things and that there is not the “best” way of doing them
  to start from scratch so you don’t feel attach to the previous code that can be worse than the one you can start in the next session
• to have 45 min sessions which means that you know you are not going to be able to implement the whole problem just to set it up so you don’t feel the stress of having to finish anything like in hackathons just the aim of learning new ways
• the option to see how things work on a different language that is not the one that you normally use, so pairs won’t be separated depending on languages

I may forget things now, but I’ll write a post just to tell about the experience on the coderetreat global day.

For the moment is all I can think of as an evaluation, I may update it if more things come to my mind.