Skip to main content

Why You (As A Developer) Should Question Technical Decisions

Many times throughout my career I've seen software developers take a lot of pain from their leaders. Throughout history, "leaders" have always been personified as an unstoppable wave in the ocean that everyone rides along with. One way--one direction--one man/woman's goal. A "leader" is the entity which has the final word. To some degree, I can't picture myself blindly following a leader without questioning his or her decisions--There has to be a reason for everything. Furthermore, you (as the developer on a team) should be asking "why" certain technical decisions are being made in specific situations. Positively, you may even end up saving a high degree of effort for your team just by having your leader realize how much of a bad mistake his or her decision was.

Decisions from a technical standpoint should always be strategic. One should always aiming for a goal to achieve and one should always have to look for key people, abilities, or events to transpire in order to make a strong, positive decision that best suits either the business or their team. Incidentally, being in the technical realm has its pains and pitfalls. In software development, a team captain has to take into account his or her experience, skill of his/her teammates, and the level of dedication they are willing to invest in building something heroic.

I live my life with this quote on my mind: "the only reason why you're unhappy is because you made yourself unhappy". There shouldn't be anyone to blame but yourself. This quote is generic enough to apply to anything: relationships, career, or school. Incidentally, from a career standpoint, I see many developers just tough it out without speaking up or challenging certain decisions from a superior officer. Ultimately: if you don't speak up and you have a feeling that a particular decision from your superior could inflict significant damage to your process, you'll end up shooting yourself in the foot.

It is always better to over-communicate than under-communicate. [Great] Technical leaders will listen to and acknowledge your opinion -- It's just a matter of voicing it out and backing up the facts. Be true to yourself. Be a developer. State your facts. "They" will listen. If they don't--then it is your time to move on.


Good luck and have fun,
Jaime Bueza


Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.
Post a Comment

Popular posts from this blog

TextMate Tutorial: How to add a Strikethrough keybind to your Markdown bundle

Markdown is awesome for quickly generating Readme's on Github. After looking at other projects using the strike tag, I've decided to create a custom keybind for it in my TextMate Markdown bundle. Here's how:

1) Click the + sign on the bottom left and click New Command.
2) Paste this into the editbox and make sure you name your command "Strikethrough".

For the input field, select WORD in the drop down.
For the output field, select "insert as snippet".
As for the keybind, you can totally map it to whatever you're comfortable with but I chose Command-D as it is the same thing in Microsoft Word.

Cheers,
Jaime

Using Git Hooks: Prepare Commit Message to automatically prepend branch names on commit messages

When you're practicing branch by feature with distributed version control, typically you'll get assigned a ticket or issue and that ends up being your feature branch. Instead of always typing in the branch name in every commit, you can edit your Git hooks (specifically prepare-commit-msg).

Assuming that this is a brand new git repository:

mv .git/hooks/prepare-commit-msg.sample .git/hooks/prepare-commit-msg
vi .git/hooks/prepare-commit-msg

Edit the file by commenting out what was originally in the file and then add this:



Now, whenever you make a commit, it should show up like this in the log:



Since GitHub and Bitbucket both support Emojis inside commit messages, you can do something cute like this



Want more emojis? check out the Emoji Mardown Cheatsheet!

NodeJS Hack Session: MMO Pokemon with NodeJS/WebSockets

The primary focus of this proof of concept is to determine how easy it is to build real-time web applications for all iPad, iPhone, droids, Safari, Chrome users on top of NodeJS (non-blocking event driven server side Javascript platform). The proof of concept was built within 6-8 hours including the following:

Uses Express framework for server side Javascript development (inspired by Rails / Sinatra / Django)Uses EJS for templating language (much like Django templates and symfony) -- allows partials and passing parameters into partials like symfony PHPReal-time chat using WebSocketsArena Queueing System for real-time competitive matchplay using WebSocketsHTML5 AudioCSS3 transitions for all hand cards, tappable cards, transparent panels, rounded corners, drop shadowsFallbacks for Firefox, IEFirefox/IE will fall back to Flash socketIE will fall back to XHR long poll if the user doesn't have Flash installedNoSQL CouchDB for fetching users and soon cards, achievements, friend associat…