heard of Bro.grammer programmers ~ what makes one

recently there was a lot of hyped discussion over what one thinks of Brogrammer

@Quora: huge discussion over everyone's definition for a brogrammer
http://www.quora.com/Brogramming/How-does-a-programmer-become-a-brogrammer

@Hacker's News: if it's a sexist term (.....seriously)
http://news.ycombinator.com/item?id=3168038

@facbook: Get with the brogram
http://www.facebook.com/getwiththebrogram

well according to the general discussion
A Brogrammer is a programmer who instead of acting like a nerd, acts cool like a bro..... dude.

Symbols of a brogrammer

• look good, always: stylish shades; dress like a hip-hopper or rockstar or be shirtless
• code hard, test hard: don't leave anything un-tested
• have a bro-tein: an energy drink
• fine gadget choice: a cool rig to use technology
• get a blanket: add on to exclusive look

Let's first make it work.....

Instead of knowing the REQUIREMENT.....

We love to show our capabilities and on our intention of delivering a better product to Client, add a lot more considerations to that Requirement.

I ended up creating an entire socket-programmed Custom HTTP Service and scrapping it off. :(

It's good. But what is not..... Is the act of delivering our considerations along-with the Requirement.

What Client wants is a robust implementation of just & just the requirement stated.
Finish that. Finish whatever more is required.

You'll always have time to come back if there is time and work on your considerations.

Several times it might happen that your considerations get served with the future requirements or get changed with the coming restrictions.
In both cases, you'll end up doing more work on it.

Though you might think Client doesn't understand but requires it.

Work on what they require first, and any problem that might come up because you didn't tackled your considerations can always be presented to them if there are collisions.

Implementing your considerations might become an overkill for actual requirement if not controlled.

They say release Beta without hesitation... I publish ALPHA

My Problem:
Wherever I see a problem... I start designing/building solution for it.

Control Issue:
When I have solution for something, I start formulating it into a prototype/project or at least a although of entire solution.

Bad Habit:
Without reaching at a stable stage on existing projects, I keep spawning new and unrelated Projects.

After Effects:
* This keeps dividing focus on existing projects' completion.
* Increased frustration for blocked projects
* Some projects don't see day-(internet)-light
* Many ideas don't get implemented 'coz fear of increasing bucket size for started…paused implementations.

I've been thinking of a solution for in past year, and then last year I started of with an approach..... tried it more this year and seems easing the situation a bit, approach to Put a Pin on what you have instead of worrying for what you don't.

Pin IT:
Get done whatever you could in the initial torque on project start so it has a clear theme and evolving design to follow.

PUBLISH it as Alpha, if you don't feel it is better than that.
I've even just mentioned the concepts for the ideas which would require much much more effort.
Your own APP (Alpha Personal Project) would be out there, at least.

This is one of ideas, I'd create a service for..... to post ideas, like Open Ideas for anyone to work upon..... when you would love to have it and don't have time/money/skill for it.

OpenChaos: http://openchaos.cloudfoundry.com

No Time-Consuming Visionary Optimizations In BEGiN.N.iN.G

Don't misunderstand me, let me make myself clear... I'm so in favor of optimized code and mostly (un)/intentionally break/fuse/remix design principles for optimized code structure.

Maximum %age of developers follow the standard principles and popular practices as a template for all of their work. It's pretty good to follow such development pattern as defining best practices specific to each and every need will highly increase redundancy and raise credibility considerations.

So, follow the most suitable design patterns... use the most efficient development platform...

and make it highly modular and universally reusable stubs...

But everything is good AT A STAGE and TO A LIMIT

[+] AT A STAGE and TO A LIMIT
If you are at initiation of developing a properly designed logic with code stubs that even have a remote possibility of being reused... should go for a generalized code.
But whats the use of spending your time in writing linked-generalized-stubs, when neither they have any chance of being used in another module, nor even being needed again in same module till any major change in requirements is there.


describing it my way, in one bad example:
Don't go RegExp matching variable, when you just have one value to match... and might need to match another value in far future.