As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I enjoy programming, usually. Tedious stuff is easy to get done as quickly and correctly as possible so I can get through it and not have to see it again.
But a lot of my coding is fun and when I get in the 'zone' I just really enjoy myself.
Which is where I make the mistake of spending too much time, perhaps adding features, perhaps writing it in a cool or elegant manner, or just doing neat prototypes.
How do you recognize this is happening before it exceeds your time frame?
What do you do before starting a potentially fun piece of code, or during, to get back on track?
When is it ok to let yourself go "hog wild" and just enjoy it without worrying about consequences?
-Adam
Keep a detailed prioritized feature list/bug list. review it often then balance the fun work with bugs/features that need to get done.
Give yourself a hard deadline--even for your own projects. Otherwise, you'll just keep tweaking and adding features ad infinitum.
Always have a working release (snapshot) ready. Treat it like the way SQL server implement snapshot isolation. :)
Continue adding new cool stuffs to a separate copy of the project. Once it is stable, overwrite your release folder and that is your new snapshot. Whenever somebody ask for a demo or release, that way you can always switch to the stable application and will have something to show anytime.
With a backlog. That way you'll always have in mind what needs to be done before you can start doing what you want to do.
Justify any "fun" features you insert by regarding them as marketable eye-candy.
Unless, of course, they're not visible ;)
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've seen a lot of developers who move across VS almost quicker than you can see. A lot of it seems to be short cut keys. I'm a terrible hunt and find it in the menu. Is there a tried and test way of getting your speed up to dome of the VS masters? Is it just memorizing all those short cut keys. Maybe removing the menus so that you can ONLY use the shortcuts? How have others done it? Are there other techniques?
EDIT
I've seen a lot of the key-binding and key code lists. But its actually going about putting in practice so that its second nature.
This isn't my forte but... print out a spreadsheet, if you will, of all the shortcuts you think you might like to use.
Plaster it to your desk. Whenever you would like to reach for a menu, force yourself to go over this spreadsheet.
Slower at first, faster in the end.
(See the link below for a list of spreadsheets from Microsoft, though you may want to reformat the data there.)
Good luck sir.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
So, those of us who've been answering questions and dealing with bug reports for a while are all deeply familiar with the concept of a "complete, minimal example". You start with a gnarly huge pile of code that's got a weird error, and you want to ask someone about it. But you don't want to send them the whole mess, so you start cutting the pile of code down into smaller pieces, until you get this little crystalized 20-line gem that still has the same bug you started with.
(And then, at least half the time, you realize what the bug is because it's staring you in the face like a luna moth, and you don't have to ask after all. But that's a side effect.)
Doing that sort of code-reduction isn't a skill that everyone has -- it takes a bit of practice, beyond the fact that a lot of newbies haven't yet learned that they ought to do it in the first place. There are several excellent sets of instructions for newbies on how to ask good questions (e.g., ESR's classic "How To Ask Questions The Smart Way"). Are there good instructions out there that explain what exactly a minimal complete example is, and how and why to create them?
It's all in the name. A complete minimal example is an example that is complete and minimal. Complete means that it contains all pertinent information, and minimal means it contains no information that is not pertinent. The ability to identify what is an is not relevant is something that only comes with practice - trying to provide instructions for this seems a little like trying to provide instructions on riding a bicycle. You can give the technical explanation and describe the mechanics (and the TeX FAQ you linked to does that very well) but in the end the only way to really learn is by doing.
I'll start this off with the ones I'm familiar with; these both come out of the TeX community, and so are a little oblique for programming. I'm hoping other people have better answers.
The TeX FAQ has an entry on How to make a “minimum example”.
That page points to a somewhat longer article on "What is a minimal working example?". Again, this is for TeX documents; the ideas are the same, but the tools and details a little different.
Edit (2013/01): Another one that I noticed in a StackOverflow comment: The "Short, Self Contained, Correct (Compilable), Example" page. Not perfect, and it suggests 20kb (!) as an upper limit, but a good addition to the list.
Edit (2013/02): Jon Skeet has a blog post about writing good questions, which includes a section on sample code that seems useful.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What are your best practices for making sure newly hired developers quickly get up to speed with the code? And ensuring developers moving on don't set back ongoing releases.
Some ideas to get started:
Documentation
Use well established frameworks
Training / encourage mentoring
Notice period in contract
From a management perspective, the best (but seemingly seldom-follow) practice is to allow time in the schedule for training, both for the new employee and for the current developer who'll need to train them. There's no free lunch there.
From a people perspective, the best way I've seen for on-boarding new employees is to have them pair program with current developers. This is a good way to introduce them to the team's coding standards and practices while giving them a tour of the code.
If your team is pairing averse, it really helps to have a few current diagrams for how key parts of the system are structured, or how key bits interact. It's been my experience that for programs of moderate complexity (.5m lines of code), the key points can be gotten across with a few documents (which could be a few entity-relation document fragments, and perhaps a few sequence diagrams that capture high-level interactions).
From the code perspective, here's where letting cruft accumulate in the code base comes back to bite you. The best practice is to refactor aggressively as you develop, and follow enough of a coding guideline that the code looks consistent. As a new developer on a team, walking into a code base that resembles a swamp can be rather demoralizing.
Use of a common framework can help if there's a critical mass of developers who'll have had prior experience. If you're in the Java camp, Hibernate and Spring seem to be safe choices from that perspective.
If I had to pick one, I'd go with diagrams that give enough of a rough map of the territory that a new developer can find out where they are, and how the big of code they're looking at fits into the bigger picture.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm needing a term or established term to represent a phenomenon our company currently calls a 'Black Hole': a project that takes magnitudes longer than estimated, yet we're already sucked in and HAVE to see it through to completion.
EDIT:
Hoping that the best term will be voted up.
I believe the term you are looking for is Death March, though I suppose it doesn't really apply if the project is ultimately successful.
I would say "Underscoped".
I am involved with an underscoped project at the moment.
"Scope creep" is the phrase I've used.
I once interviewed for a position on what had to be the ultimate Death March project. I was at Lockheed Martin at the time. Here's what I discovered at the interview:
The project was almost entirely staffed by engineers pulled off of the layoff list. Pretty much the dregs of the company.
They were using castoff equipment from the rest of the company for their software development.
15 hours a week of overtime was mandatory, and would be for the foreseeable future.
They didn't even have cubicles. Everyone worked in one great big open bullpen with wires strung everywhere.
They had attempted to deliver this project once before, but the customer rejected it and made them try again.
They were so far over budget and so late that nobody was even bothering to track it anymore.
They wanted to cancel the project, but their customer was the government of Egypt and they were threatening to stop a large order of F-15s until this project was delivered. (The project had nothing whatsoever to do with F-15s). So now they were getting pressure to finish from the Chairman of Lockheed Martin on down.
Engineers visiting the customer site in Egypt had come down with nasty staph infections. One had to be medevacted out to Europe.
I swear I practically ran from the room.
Since hours are often associated with cost, perhaps the term you seek is Cost Overrun?
I also like the concept of Optimism Bias as the reason for under estimating.
I remember 'logic bombs' applied to compressed files. Mainly, create a (back then, several gigs) file containing only one symbol repeated over and over. Zip the file (will become tiny). Send to user -> balloon effect.
Perhaps balloon project?
Murphy's Project?
Spike may be useful in trying to get these under control but it isn't quite what you want.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a team lead who seems to think that business logic is very subjective, to the point that if my stored procedure has a WHERE ID = #ID — he would call this “business logic”
What approach should I take to define “business logic” in a very objective way without offending my team lead?
I really think you just need to agree on a clear definition of what you mean when you say "business logic". If you need to be "politically sensitive", you could even craft the definition around your team lead's understanding, then come up with another term ("domain rules"?) that defines what you want to talk about.
Words and terms are relatively subjective -- of course, once you leave that company you will need to 're-learn' industry standards, so it's always better to stick with them if you can, but the main goal is to communicate clearly and get work done.
One way to differentiate is that "business logic" is something the customer would care about and that could be explained to a customer without referring to computer-specific words.
You could try to argue your point with a timed example, run a sql select against an indexed table and then run a loop to find exactly the same item in the same set but this time in code. The code will be much slower.
Let the database do what it was designed to do, select sets and subsets of data :) I think realistically though, all you can do is get your team together to build a set of standards which you will all code to, democracy rules!