Interesting Reads 3/15 - 3/21

A fairly diverse set of reads this week from agile development, to being a better programmer, to some cooking related things. Lots of good info in these, mostly short, posts and articles.

Enjoy!

Why Agile is failing

A great read on holocracy. One of the highlights for me, "Dysfunction happens any time somebody can't do something because they need permission, or won't do something because they're afraid of some repercussion."

The corruption of agile

"Don't burn yourself out to be a better programmer"

7 years of culinary science

No one knows what they're doing. Favorite quote: "The good news is that this makes you very not dangerous. The bad news is that it also makes you feel dumb and helpless a lot of the time."

Making technical decisions. Really interesting talk by Sarah Mei.

Sandi Metz's most recent talk slides. Can't wait to see the video!

So Many Random Learnings

I love learning and in the past few weeks, I've learned so much!! In lieu of a more organized post on this stuff, here’s a random smattering of what I’ve learned the last few weeks.

Ls –lM lists everything in list form
Git rebase –i sha is what you use in order to squash commits

Git rebase master… I’m still learning the process and exactly how to troubleshoot this but it seems standard in worksflows that require pull requests and it’s pretty interesting to solve merge conflicts.

Debugging (with capybara): insert a save_and_open_page to see what page/path opens

Alfred workflows are amazing. I’m trying to train myself to use my mouse less. My wonderful mentor suggested that instead of going cold turkey on the mouse, I should start by getting good at just a few things. So, I’m starting with Alfred workflows and trying to get better at not using my mouse within my text editor (sublime).

Alfred workflows that I have set up include spotify, dash, and being able to search for any file or folder on my computer. I’ve got the git workflow partially set up.

In Sublime text, one of the most useful things I’ve learned recently is CMD + . will switch back and forth between the test file and file being tested. CMD T allows you to type to open a file. Just to name a few.
Option and highlight lets you highlight the first letter of each line


Git commit (without –m, etc.) will open your text editor so you can do the commit message there, save it, close it and it’ll bring you back to the command line and finish the commit
Git checkout – brings you back to the last branch you were on
Git rebase –i HEAD ~1 rolls back 1 commit (~2 rolls back 2 commits)

From the command line putting touch and then the path with the filename at the end will create that file

When squashing commits (which means making multiple commits into one commit), you always ‘s’ (squash) the second one

Gem railroady produces a UML diagram of your code structure

Kill process… somehow I created a connection with a server and then I created a second connection with a server and then couldn’t get one of those connections to close!
ps aux | grep finds the process so you can see if it’s running (I’ve since used this ps aux | grep ruby and ps aux | grep puma)
Then kill -9 prodID (number all the way to the left) kills it. Alternatively, you can also kill it by doing killall -9 thin (or whatever you’re trying to kill)

Interesting Reads 3/8 - 3/14

First I have to read all the things I bookmarked for the week, then I can make the post of which of those things were interesting. Here's the list for this past week. Not too much actually, but what's here are some pretty short posts that are quite interesting.

Enjoy!


This week, I've been getting up close and personal with pivotal, learning it's tricks and how to better write user stories for the current build. Here's a great piece from a little while ago about some good guiding principles.

Using Pivotal for setting time estimates on chores and bugs... or not

Some interesting info on RailRoady, a cool visualization gem

I've been trying to learn more about all the words mentioned in this article (background jobs, multi-threaded, etc.). Chris mentioned Sucker Punch to me a few weeks ago. I haven't used it yet, but this post gives way more info about it which is nice.

Learning to Code is NOT Easy

In the past few months, the necessity to learn to code has been everywhere. It seems as though everywhere you look, someone is telling you to learn to code and there are very few dissenting opinions. With this push to learn to code has come a proliferation of bootcamps and other “accessible” opportunities to become a developer without necessarily needing a background in computer science.

But the idea of shoehorning people into a career and encouraging them by saying that learning is easy is a dangerous notion that hurts both individuals and the industry as a whole.

Learning to code is not easy, it is however, achievable and there is a big difference between those two words. You can learn the basics and know how to code, but to actually be a good developer takes years of practice and dedication. It is a craft that you need to constantly work on and improve upon. You can see this through the numbers of books and podcasts and meetups and mentorship and tutorials available to those in the field at all levels. Good programmers know that there is always more to learn and always ways to grow. They put in time during work and after work to continue to work to master their craft… and they love it.

Just like anything else, it takes hard work and dedication. You can learn to code in a short period of time, but it definitely doesn’t just happen. Oftentimes, people ask me how I learned so quickly (more often the question goes “Is it really that easy that you just started teaching yourself and were quickly coding and looking for a job?”) My answer is that no, it isn’t easy, but it is doable and in order to achieve what I did, I made as much time as possible. I go to meetups most nights of the week, code every day, and sacrificed other things so that I could make that time for myself. And to be honest, the thing I love most about coding is that it is constantly challenging and that there is always more to learn. For me, it’s not just the cool thing to do right now, and it’s not an easy path to making the big bucks. If you’re not passionate and you don’t do it for fun, you’re going to hate coding as a career.

There is a fine line between false advertising and being afraid you’ll discourage people from joining the industry, but we, collectively, are doing the industry a disservice by advertising that learning to code and becoming a developer is easy.

Here are some great articles I found along the way:
https://www.codefellows.org/blogs/this-is-why-learning-rails-is-hard
http://happybearsoftware.com/how-to-survive-your-first-year-as-a-programmer.html

Final Gem Post- The Action Class

This is a little out of order since it's been a while since my last post on the gem I helped build, but I wanted to get it out there. Feel free to refresh your memory by re-reading these posts 1, 2, and 3. The action class is a small, fairly simple class that is mostly used to just outline all of the attributes in an action item and then also distinguished a few method for specific attributes which are more common or may be requested more often.

The whole class looks like this:

class Action

  attr_reader :attributes

  def initialize(params) 
    @attributes = params
  end

  def title
    @title = attributes['title']
  end

  def description
    @description = attributes['description']
  end

  def reference_name
    @reference_name = attributes['reference_name']
  end

  def action_key
    @action_key = attributes['action_key']
  end
end

The initialize method sets up the class by just creating a hash that is the attributes hash and then the rest of the methods are just pulling out specific pieces from that hash. I’m not sure if by the end of this project, this class will be separate, but to me, it felt like it was doing different stuff than the ActionFetch class so I chose to separate it out.

Interesting Reads 3/1 - 3/7

A day late is better than a week late. Here are the interesting reads (and watches) from this past week.

Currently, I've been working on a bunch of analytics-related queries and tools. I came across this video about measuring which was really useful.

ember, ember, ember!!: http://www.confreaks.com/videos/2597-lonestarruby2013-ember-on-rails-realtalk

I rewatched this amazing Ben Orenstein talk this past week, refactoring from good to great. I had watched it a few months ago and a lot of the concepts went over my head so it's fun to see how much I've been learning!

Related to the questions I have as a professional programmer, some days are good and some days are bad. This was a great article that helped me realize everyone goes through the same roller coaster.

For Fun.

Beefing up those Comp Sci chops

For anyone who's been asked to FizzBuzz

The Maker's Schedule. An old article but still relevant.

New Questions as a Professional Programmer

There are a few steps, I think, in my early days of learning to code progression, where I feel as if leaps were taken. The first is when you start coding. There’s a lot to learn just about the basics at the beginning. The second is when you start tutorials… going though each of the steps, really processing everything and beginning to figure out what to do when you encounter errors and issues. The third happens when you move from tutorials to building your own thing. You’re no longer following directions. You are in charge of scoping out features, thinking about architecture, and solving errors and issues that others may not have encountered exactly. The last (so far) is when you start coding professionally (and getting paid for it). This involves learning new workflows and processes, integrating into a culture, and learning new languages and technologies to name just a few. Through each of these stages, I’ve developed a new set of questions and new things to worry/stress about. I think these questions also change depending on what phase you’re in. Over the last few weeks of coding professionally on a small development team, here are some interesting things I’m thinking worrying about on a regular basis.

1. Learning on the job is tough. The specific project I am working on is mostly written in Ember. It’s been a fascinating language to learn (especially since I previously didn’t have much of a background in javascript at all) and I’m definitely learning much faster since I’m building components and working in the language while learning it. But it is tough to learn amidst deadlines and due dates. How much do you need to know? Am I building things correctly in this new language?

2. How much time should I spend on something? This is a tough question. I want to learn and make sure I’m implementing the best solution but at the same time, how long do I take on something before I either move on, ask for help, or just put the best solution I know in place?

3. What is the normal “getting stuck” level? I feel like I get stuck at least once a day. Whether it’s something confusing on git, or a test that is failing, or some functionality I’m putting in place, every day I spent at least an hour trying to figure out how to move forward. Is this normal? Is it not? How much time do I spend “stuck” before I ping someone?

4. This is related to the question above but… when am I learning and when am I spinning my wheels? There’s nothing I hate more than pinging someone for help only to learn that the solution is super small and silly. I know this happens to everyone, but it makes me feel like I SHOULD have seen the solution and not bothered someone else. But then, there are times where I am reading EVERYTHING out there and googling and researching and breaking a problem into pieces and I wonder, am I spending too much time on this?

5. How much of the process should you follow? There are lots of process “things” in the programming world. Whether it’s test first, write code in the red, green, refactor order, spend time refactoring in general, pair, do code reviews, etc. I love all of these things, but I find myself weighing what process I should follow and how strict I should be with the process, knowing that there are deadlines and things that need to get done. I know it makes sense to do something the long way and then refactor, especially since as a newer developer I’ll learn more that way, but is it always worth taking that time? Sometimes worth it? How long should I spend on writing code vs. refactoring it?

This first position is really fantastic. I feel lucky because in most initial programming positions, developers find themselves doing one type of job or spending months on the ramp up. I was thrown into the deep end a bit from the getgo (which I almost prefer) and I get to do different things every day… rails, ruby, database stuff, javascript, etc. It’s great… wonderful and challenging but also stressful. I look back at the last four weeks and think of the crazy amount of information I have learned. It’s so different than self-teaching and working on projects that I created or things from scratch. And yet, it raises a whole new set of questions in my mind. I imagine that other developers feel the same way… especially in their first position.