Estimation has been deemed insensible by many. Some called it a "waste of time." I thought it was merely due to business as usual. Even when you work alone on your own project, it is frustrating when you’re always wrong about timeframe for completing a project. If you have 50 tickets today and you can finish about 10 to 20 tasks in a day, you should be done in less than a week but why are you still working on the same project the next week? Because there are more tasks to be completed than you have initially expected.
The Devil and God is in the Details
Unperceived delays lead to frustration and potentially bankruptcy. I dislike over-optimists because they do not see the details. Both “God and the devil are in the details.” Whichever side you take, over-optimism without a good intuition is far more frustrating than being a pessimist with a plan.
Psychologists say that not everyone is good at work that requires “attention to detail.” Majority of managers aren’t that kind of person as “attention to detail” is delegated. This is a funny fact you have to accept as a developer.
Why is It Difficult to Start Projects?
Whenever you start a project, you may find yourself doing a lot of configuration work and you do it for every single project over and over again. This is why “hackathon starters” or quite simply, project template creators make sense. I started compiling a list primarily for the upcoming #hack4good event. You check the following links:
We’d greatly appreciate contributions to that project.
The list is helpful for both “single-page” application startups or otherwise. It’s funny but true. I found someone who found a market and made a single-page application website that works very well for that market.
These projects make a lot of sense because many developers think that an app that works in development or their computer should just work in production. This is not true. Why? Details. What are common things missed by developers who think “there should be no problem”?
If you’re using Heroku and you want to deploy a Python or Ruby application, there’s a high chance that your “app from scratch” is not configured to support Gzip compression.
How is this done exactly for Ruby on Rails applications?
# config/environments/production.rb config.middleware.use Rack::Deflater
This is true for Python or any language. Sometimes it goes beyond missing trivial lines of code (and everything is trivial!). Sometimes we forget to do necessary validation. Consider a date range (start date and end date). Would you deploy that project with just validation of presence for those fields?
Perfect is the enemy of good but being wrong is enemy of success. This is true when you completely disregard security issues.
Automate code reviews
It’s important to automate code reviews similar to how running a test suite is automated. We use the guard project for these tasks. It’s good have these dependencies on your Gemfile if you are using Ruby.
gem 'guard-rspec', require: false gem 'guard-rubocop', require: false
Even if I saw a few gotchas with the rubocop gem, I found it good tool for ensuring code quality as it goes beyond checking for trailing whitespaces. It ensures you are not using conditionals when it’s not necessary. It helps you reduce overall complexity of code and possibly makes it a lot more secure. When a “cop” is not sensible for a project, you can always specify that it should not be used for your project through the configuration file. Check the cops if you haven’t yet.
What commonly-used dependency do I hate? Devise. While documentation is good, I still found myself updating their wiki because of “deprecated or obsolete” recommendations. I’ll be using sorcery more for some projects probably .
For the upcoming hackathon, we’d allow custom templates as long as they open source and published on Github. It’s a rule for hack4good Baguio. I am expecting a few very good developers to join but not a lot. It should be worth the time and hopefully, it would be a good learning experience for us all.comments powered byDisqus