How’s that now?
Yup, I wrote those lines. I’m guilty. And you know what else? I’m glad. Embarrassed that you saw it. But glad.
You see, I wrote that when I was younger (well duh), but I wrote it thinking it was done to the best of my ability. It wasn’t out of laziness, nor was I defecting*. It could have been due to timelines, but in general, I thought it was right. You thought so too so it passed peer review. We were all younger then.
I wrote that 1 year ago, 6 months ago, 1 month ago, yesterday.
I feel fortunate that I’ve grown as a developer and communicator. Grown so much that I can identify how that code sucks and how it can be improved.
Hopefully today’s code will be shit one day too.
In a recent Melbourne cocoaheads meetup a friend who works as a Software Development Director got up during the ‘Who’s Hiring’ segment and pronounced that they’re looking for smart people. She was promptly followed by another who were also looking for someone smart.
Afterwards at the pub I jokingly asked her if you really had to be smart and whether you can just be funny? I’d interview for funny.
All joking aside, it got me thinking whether being smart is all it takes to get the top development jobs.
Objectively speaking being smart brings a lot to the table:
- you catch on quicker
- you get things done faster
- you find solutions others may not have thought of
- you can work autonomously without supervision
But being smart doesn’t mean you’ll be pleasant to work with. Being smart doesn’t mean others will benefit from being associated with you.
It’s possible to be smart and be a horrible boss, employee or colleague. You can’t guarantee that a smart person can explain a concept to another since they appear to understand things instinctively. It also takes a lot of patience for someone smart to wait for others to catch up.
So if it’s not just smarts that make someone a desirable candidate, what else is there?
I’ve met and worked with smart, quick, extroverted, introverted, slow, detailed, funny and dull developers. They all deliver what the say they would. And of course the ones I personally want to work with time and again are the funny ones. (They keep you feeling young from all the laughing).
And if you can’t get the smart or funny?
Well then I’d aim for the detailed, the patient, the passionate and the hard working. Everyone has something to contribute, and hey, the smart people needs someone to learn from too.
Having always joined an existing team meant that I’ve never had the chance to setup a private Podspec repo on my own.
It turns out to be simple enough. For the official guide, go to http://guides.cocoapods.org/making/private-cocoapods.html.
So why would you want a private CocoaPods Podspec repo?
Its the preferred way for maintaining any private pods libraries. Instead of pushing these private pods’ podspecs to the ‘master’ spec repo you can manage them here.
Where are the spec repos kept?
The spec repo is located under your cocoapods directory:
In here you’ll find the ‘master’ spec repo which is a clone of https://github.com/CocoaPods/Specs.
So how do you go about creating a spec repo?
Step 1: Create a directory where the spec repo should go. For me it would be named ‘MHSpecs’. I’ll keep it within my iOS_Proj directory
$ mkdir MHSpecs
Step 2: Cocoapods expect a spec repo to be git repository so lets go ahead and make it one.
$ git init ~/iOS_Proj/MHSpecs
Step 3: Make the MHSpecs a cocoapod podspec repository. I’m using a local url until I’m ready to publicize it. You can easily have this hosted on github and replace the url as needed
$ pod repo add MHSpecs file:///Users/micah/iOS_Proj/MHSpecs/
Step 4: Confirm that MHSpecs has been added to the repos directory
$ ls ~/.cocoapods/repos
Now when you want to add a private pods’ podspec to this repo you just need to specify the repo name when you push the podspec
$ pod push MHSpecs MHPod_Name
Easy steps to set up a Github Page → http://pages.github.com/
What is the first thing you'd do if you can be invisible?
Go see a movie.
Your turn, same question
I'd conduct a user experience test
This is the story of a refactoring.
It is not a glamorous story; it does not have a happy ending:
Once upon a time, a story card was picked up by a developer who, after reading through the feature description thought
'wow, this would be a great opportunity for a refactor, that piece of code is picking up a stink’.
A branch was created and a test was written, a feature added, and then another. Some discussions were had between developers and the feature developed. Then one day, the developer reach the point in code and began burying their head in the their hands.
they thought, if this area was left as is, there’ll be more tech debt accrued. And so, a refactoring was born.
At first, things went well, an extraction here, a dependency injected there, but wait, where were the tests?
‘alas, these are in a view controller, and we don’t have tests for them’
The developer rationalized that since it can be tested manually by building the app, not having automated unit tests would be ok.
'So now the dependencies would need to be created and passed to the view controller. And then maybe another class should be created to encapsulate these dependencies. But this new class should then be passed to this other view controller as well.’
And so, the refactoring grew. And the clock ticked on.
Now, this was a pragmatic developer, who after coming to the realization that this is no simple refactoring decided to do what all pragmatic developers would do: stashed the refactoring - gave it a name.
Now I mentioned that there was no happy ending.
The developer never got the chance to return to that stash. The code base progressed. There were new features and new ticking clocks. In the meantime the stash grew stale. Maybe one day, through chance the developer might look into their list of stashes and be reminded of one called “refactoring”.
— This story was written for the Refactoring Awareness Campaign, no refactoring left behind.