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 laptop and bunch of 5 min segments throughout my day. I used to think this was simply too short a time to do 'anything'. Though with a little practice and a few minor behavioral changes (like unplugging) I have realized that I can get something done in each segment. So now I am reaching out to all you quick-draw-programmers out there for more tips that will let me get something done in the shortest time segment.
What did you do?
How long do you work?
Here's an idea: when you have larger chunks of time, write some unit tests for functionality you plan to implement. Then, when you have a 5 minute increment, choose a test and write code to satisfy it. This way you aren't spending any of your 5 minutes deciding what to work on, you already did that and documented it in the form of unit tests.
And hey, you get TDD and test coverage for free. Bonus.
Adopt Test Driven Development.
A big cost in task switching is figuring out where you were last.
If you always write the test before you start, it's a no-brainer to pick up where you left off. Run the tests, whatever fails, that's what you do next.
Believe it or not, there's a website called Five Minute Videos, and they have a Software section.
http://www.5min.com/Category/Tech/Software
Read through random posts on SO and learn something new :-)
Boring back story: I was in a similar situation when I had to look after my ten year old sis for a day. While we were waiting for a friend to come over I really wanted to get some features done on a personal project.
I found that playing a ~20 second acoustic bit of music and clearing my head before I wrote anything was really useful, along with spending the first 5 minutes making a threadbare list of things I wanted to complete.
Massive use of TODOs. When you start on a new class (I'm a java programmer), write all the method names, and TODOs instead of code, this usually takes (the infamous) five minutes. Then, when you have your next five, start with chosing a random TODO, and write the code. I prefer doing them in a random order, but you might find that writing all the TODOs in a method first works better, just try:)
As I'm not a full-time programmer, but a student and hobby-hacker, most of my programming is done at home, the library or a cafe. I'll complete one or two TODOs, and surf the web a bit, watch people walking by, order a new coffee or get some snacks from the kitchen.
This propably won't work in a production-setting, but for personal projects it's king!
Learn all the keyboard shortcut keys.
I also sometimes program in short bursts, like while waiting for trains. My method is to throw an exception that says 'TODO: Next step is to return a query here'. When I open my laptop, I run the module I'm working on and it blows up, telling me what to so with a stack trace telling me where in the code to start.
Also, don't ever bother closing your IDE...
Project Euler!
Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems.
http://projecteuler.net/
Also you can read The Daily WTF, 5 minutes worth spent.
I think the biggest hurdle is knowing what task can fit into 5mins. So the first thing I'd do is break down a bigger piece of work into a bunch of bite sized tasks, each of which will fit into 5mins. That way when you have your spare 5mins, you don't have to context switch to a large problem, then try to work out what needs doing & then try to get something done. Instead you just look at your task/todo list & grab the top item.
Programming involves two processes: thinking about your program, and typing the code into the computer. Try defining everything into small projects that should take no more than ten minutes. If you pre-compute what you want to type in and learn how to type well, you can knock some good work out in 5-10 minutes.
I use standby on the laptop instead of Hibernate because it gets me to the IDE faster. I had expected to have battery problems because of this but it seems to work quite well.
Read a few pages of Code Complete 2
I think an answer to another question has a good idea. jalf suggests:
A very simple trick might be to
subscribe to the RSS feed for C++
questions here on SO.
A wide range of questions get answered
here, on every difficulty level, and
they generally get very detailed
answers.
It won't replace a good book on C++ of
course, but it might be a good way to
discover a wide range of concepts,
pitfalls and solutions you might not
have known about otherwise.
So when you have 5 minutes here & there, check out an RSS of a particular tag in Stack Overflow and read (and answer?) questions.
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.
This may be a hopelessly vague question. But I am interested to hear whatever logical thought processes people go through when learning a new concept or trying to get their brain around code they might not have ever seen before.
Basically, what general steps does one take to to break down problems and what does it take to "get it"? If you were to diagram a flowchart of how your mental process works when you look at code or try to solve a problem what might it look like?
What common references, tips, and mental assumptions do you find useful in problem solving?
How is this different between different domains? For example in what ways is a web programmer's thought process similar or different from a traditional desktop app developer's process?
I'm a big believer that no matter what type of application you're looking at for the first time, may it be a web app, a desktop app, a device driver, or whatever else, there are three steps one developer usually follows in order to understand how it works:
Get the big picture :
What kind of app is this (web, desktop, ...)?
How is it layered (standalone, client-server, n-tier, ...)?
What is the app's purpose? What is it supposed to do?
Who is the app made for?
See how it works :
What language(s) is (are) used?
How is the code structured?
How is the data structured?
Understand (or at least try to) the way the app has been thought through:
Has it been thought through at all?
Is the app clearly optimized? (For performances? For readability?)
Is the app finished? Or is there room for evolutions?
Are there signs of multiple releases?
etc...
The 1st and 2nd steps are purely technical, while the 3rd MUST be as untechnical as possible... it's more about psychology and understanding how the app has been built. It obviously requires experience, but as long as you think hard enough and don't waste your brain's time with technical details, you'll eventually get it.
This whole process shouldn't require the use of a keyboard. You're only supposed to read, think, and take notes on a paper (I'm not kidding: pen and paper!).
Ho ho, good luck with this one. It's a great question and I'm sure you'll get a ton of answers. Although I have to say I cannot give a satisfactory answer to this - the last thing I would describe my thought processes as is a flow chart - I don't think there is any golden formula for this.
The only tip in problem solving I can recommend is discussing it with somebody else. In those times when you hit a brick wall, going through it with a colleague is invaluable. Quite often, as well, they will actually not even add much to the discussion - in the process of getting all your thoughts out in the open, the solution can become clear.
People are notoriously bad at examining their own thought processes, but I'll give it a whirl. I test very high for visuo-spacial ability in IQ tests, medium-to-high for verbal skills, and moderate for mathematical skills (explains my A-level Maths grade, I suppose). amd when I start to design software, I think in terms of shapes and the connections between them. When it comes to describing these thoughts to others (or clarifying them for myself), I use simple block diagrams or the object diagrams taken from Jacobson's Objectory method - NOT the over complex stuff that UML suggests. I sometimes write textual descriptions of complex things, mostly as reminders to myself, but never use numbers or maths.
Of course this is just me - I've worked with maths whizzes who were just as good or even better programmers than myself.
I don't think... I process.
This is actually less flip than it sounds. I always break down tasks into their components and then break these down further, and that doesn't just go for writing software! Much like #Mark Pim U go through things sequentially.
My wife gets really annoyed when I make dinner because I take so long to get started.
Divide & Conquer
I start by trying grasp the entire problem as it is, and then start to find patterns I can recognize, and do the same for them in a kind of recursive process, until I have a broken down solution I can implement and follow more easily.
This is one of the rare times I would answer with "it just works." I learn things by steamrolling through them. I don't have gimmicks, or devices to help me. Took me some time to learn PHP, but after that Javascript was much easier. Once you tackle one thing, the next items become cumulatively-easier.
Personally, I conduct an internal dialogue with myself 'OK so we need to loop over this list of integers.' 'But we can break when we find the value we want.' 'OK, will the list definitely be initialised when we start?'
I'd be interested to see if any psychological research had been done on problem solving techniques.
Similar to Jonathan Sampson - it kind of just works.
When I'm attacking a real problem, I try and think of the most logical way of getting through it is.
Then, when everything goes wrong (as it usually does), I have to make hundreds of sidesteps to get things done. Just keep focusing on that end goal, that logical way and you'll get there.
Eventually though, it decides to work for me and I end up with a finished product that is usually nothing like I planned it out to be. As long as the customers are happy, I am!
Personally, I see code in my head pictorally rather than textually (like Neil Butterworth) - it's a bit hard to describe since (quoting STIV) "there's no common frame of reference."
My main skill is identifying similarities between models or systems I already know about and the task at hand. The connections between some of these can seem quite abstract; the key is to spot the connections. This leads to the abstraction of common patterns and approaches which are widely applicable. Related to this, the most important thing I learnt about algorithms was that the problem is never 'come up with a smart algorithm to solve X'. It's 'model problem X such that it can be solved by existing smart algorithm Y'.
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.
It happens fairly frequently that I'll finish up a big project or get done with a meeting around 30-45 minutes before my time to go home. There are usually things that need to be done, but it usually isn't worth it to start on those projects with only 30-45 minutes to go.
What are some good things to spend that time doing?
Here are a few ideas.
Check StackOverflow.
Check RSS feeds.
Handle and delete three email messages.
Write a couple unit tests.
Put a few comments in your code.
Delete old files and defrag your hard disk.
Take a look at your calendar and to do list.
Write someone an email thanking them for something.
Build a project you haven't touched in a while to make sure you still can.
Browse through the documentation for some software you use frequently.
Project Euler. Easy way to burn that 30-45 minutes without committing to something big. Plus, you're working on problem solving, algorithms, and sometimes even learning new features of your language while doing the problems.
Answer a few questions on SO.
These are precisely the times I spend updating documentation (i.e., wiki/knowledgebase documentation, not to be confused with inline comments). I don't want to write any code with only 30 minutes to spare, but I can put together a nice knowledgebase section or article in that much time.
Start on something big that you know you don't have time to finish. Leaving it incomplete (and, ideally, in a marginally 'broken' state) will give you something specific to do when you get back the next day, which makes it easier for many (most?) people to get back into the groove quickly.
Make a to-do list for tomorrow.
Cleanup some code formatting.
Flirt with the receptionist, then slink away in abject failure.
When I have a chunk of time that's just too small to do anything really complex or intensive with I will try to do one of a few things:
Catch up with any outstanding communications (reply to emails or voicemail) or check up on people that I'm waiting to hear back from.
Make any adjustments to design documentation to reflect changes that were made in the day
Cleanup my work environment - I end up with a lot of temporary files and such that need to be pruned or removed on a regular basis
Try out some idea or thought that I've got in a scratch project that I don't want to interrupt me while I'm actually "getting stuff done" as it just might not work.
Overall I just try to do things that either require less investment or are easy to step out of.
Go through your GTD system, sorting out of your inbox and updating your "someday" bucket.
Or just grab something small out of your "someday" bucket.
Invest this kind of time in small things that will help pay off later.
Write some bash scripts that automate things you often repeat
Learn some more Vim or Emacs shortcuts
Tidy up code (fix indentation, remove unneeded commented-out code, add useful comments)
Write test cases
Take a walk and stretch, your hands and back will thank you later
Write yourself a note about what you accomplished today and what you hope to accomplish tomorrow.
Start a chat with some of your friends. After all some other things should be done also apart from work.
Two suggestions...
Post questions/answers on stack overflow.
A nice book and a 45 minute bathroom break!
Start learning something you don't know but find very cool.
Help your friends to finish up their work, so you all can go a get a beer together.
Go over your day's notes, talks, discussions and ideas and see what should be saved before the post-it notes and whatever gets thrown away. File it in tasks, the calendar, or your todo.txt file. Reflect on what you did well, and what you could do better.
Start a small project in a new technology (something you may use later) or a new approach to something that may replace something else later.
Go through your todo list for some quick work to do.
Refactor something small. There are always bits of code that, 5 minutes after I'm done, I realize I could have taken a slightly different approach that would have been "better" in some way.
Implement a small feature/improvement that you've had in your head for a while.
In most cases I use that time in order to review code I wrote a long time ago (it helps me see problems or get ideea on future improvements) or to write/update documentations.
Sometimes I revise my task plan for the next days.
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 often work with sales and marketing types that cannot figure out how to use Excel, let alone understand the scope of their requests from a technical perspective. Of course, it would not be fair to expect them to, but that still leaves me with a problem.
What is the best way to show marketing and sales types that they have asked for something that requires a lot of complex programming and some patience?
Could you please share examples of problems and solutions?
Could you please recommend books on this subject?
Thanks!
Break the problem up into as many sub-divided tasks as possible. Provide a per-item estimate in hours beside each one.
When they think of a project as a whole, it seems simple. However, when they see each individual thing that must be done and the number of hours each item will require, it is putting it into terms business people can understand. Suddenly the software solution they want isn't a "black box" to them anymore and they now have some insight into the process.
If you are looking for books I would suggest Software Estimation - Demystifying the Black Art.
The computer will do what you told it to do, not what you want it to do.
Any form of abstractions needed be translated to exact details.
source http://c2.com/cgi/wiki?TeachMeToSmoke
Teacher: "It's hard to express ourselves clearly. You're a smoker, right?
Are you pretty good at it? [Student nods.]
Let's pretend I'm a man from Mars and you are going to teach me to smoke.
Do you have a fresh pack? Let's start with that.
[Takes pack.] OK, now tell me what to do."
Student: "Tear open the pack."
T: [Tears pack to shreds. Cigarettes fly everywhere.]
S: "No, no, tear off the top of the pack!"
T: "OK, sorry, do you have another pack? No? OK, let's just start with this cigarette. [Picks one up.]
S: "Put it in your mouth."
T: [Puts whole cigarette in mouth.]
S: "No, no, just put the end in your mouth!"
T: "Sorry." [Tears filter off, puts whole filter in mouth.]
S: "No, no, don't tear the cigarette, just hold it between your lips!"
T: "Oh, sorry, give me another one." [Places new cig sideways between lips.]
... and so on. You can play the game for a long time. It's hard to give clear instructions, even when you know the domain. Programming will endure for a long long time. -- RonJeffries
I had a friend who could do the Rubik's Cube in seconds.
That made me think of this way of explaining to my manager why did our latest project FAIL!
Olivier takes an average of 10 seconds to completely sort all colors of a 3x3 Rubik's Cube after looking at it for approximately 5 seconds.
If you ask him to make an estimate of how long it will take to sort it, you give him the cube, start the clock and after 5 seconds he will say:
"OK, as soon as I start I will be done in 10 seconds"
you smile and say: "Start!"
After 3 seconds you ask him to stop.. give him another Rubik's cube and say.. sort this one instead...
4 seconds after he starts the second Rubik's cube, how long do you think he will take to sort the first one again?
If you answered 7 seconds approximately, congratulations: You're upper management material!
(and Olivier would be rightly entitled to force you to eat the cubes)
I agree with Simucal in the sense that managers tend to do better when you break a problem into hours, rather than into programming tasks. For example, saying to your boss, "That should take about two hours to complete, but I have a few other things that I have to complete first, so I should have it to you by tomorrow." is a lot more useful than saying, "Well, first I have to design an interface to communicate between objects, and then create the classes to implement the interface, and so on." Managers understand what they can see, so anytime you can explain your task in terms of end-user effects, you will likely have more success.
With that said, don't let your manager intimidate you into making promises that you can't keep. You may know that all they want to hear is "I'll have it by the end of the day.", but if you know it can't be done, don't say that it can, hoping that if you have it to them sometime in the next couple days, that it will be "close enough". If you start factoring in time for designing and testing and give them appropriate estimates, eventually they will start to understand how long it takes to accomplish certain types of tasks, and stop expecting everything to be done by yesterday.
I've also noticed that tangible results along the way tend to put their nerves at rest (temporarily, at least). My boss starts demanding finished results when he starts to panic as to whether or not a task will be completed on time. However, when he is able to "see" the step-by-step progression, then he is more likely to understand that we are, in fact, making progress, even though it isn't in the finished product yet.
Also, as you start this process, try to look at things from their point of view, and understand that until you get to a point where you can spend the amount of time you think is necessary, you may have to find a happy medium. There came a point in my experience where I needed to develop a Cache object, and while I would have loved to take several weeks to design and implement a configurable and extensible Cache that could be widely distributed across multiple applications, I had to limit myself to the task at hand. Just make sure that if you decide to scale back or follow through with a short-sighted design, be sure that it is well-documented so you can go back and fix it when you have time (or so another developer can pick up on the train of thought that you were unable to finish). Also, don't sacrifice good coding standards and style, as this will also make your code easier to maintain and update properly in the future.
Good luck!
This one may be a good book for non-programmers to understand some of these issues and pitfalls of runaway requirements:
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
In all seriousness, I think the best thing it to actually tell them that some things are complex and do require complex problem solving, analysis and design. There is a gap between what they do, and what the programmer does and its unfortunate that they will never understand the full implications. You sometimes just have to be firm and explain that it can take alot of time.
Perhaps a breakdown of the task into subtasks and giving them estimates may help.
Make sure you understand their issues too. People will often bring solutions to the table ("we need this feature") rather than start with root business needs. The more you understand the problem the more likely you are to be able to suggest a compromise.
On occassion I've been told a certain large feature is absolutely essential, but I've been able to deploy much simpler solutions that substantially addresses the problem. Sometimes these interim solutions have grown into vital features, just as often I've been able to remove them two releases later without anybody noticing.
In my experience, whenever I started to explain to sales people in the past why a task takes a certain amount of time, they quickly admit that they do not really want to know the technical details, and I am fine with that. I usually do not want them to explain to me why they still have not nailed down that big sale after n days either. To do work effectively, everybody has his own area of responsibility.
Just make sure that your relationship with the sales people that you provide estimates for is good and they trust in your ability to do proper and reasonable estimations and get the work done. IMHO there should be no need to explain and reason an estimation in every detail, but if there is, I would say the real problem lies elsewhere.
And I wholeheartedly agree with "It depends" above.
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.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
One of the companies required from its prospective employee to give the number of lines of code written in the life time in a certain programming language like Java, or C#. Since, most of us have a number of years of experience in different projects in multiple languages and we hardly keep record of this, what would be the best approach to calculate this metrics. I am sure the smart members of stackoverlow.com will have some ideas.
This is a very respected company in its domain and I am sure they have some very good reason to ask this question. But what makes it also difficult to answer is the type of code to consider. Should I only include the difficult algorithm that I implemented or any code I wrote for e.g. a POJO that had 300 properties and whose getters/setters were generated using IDEs!
The best response to such a question is one of the following:
Why do you want to know?
What meaning would you attribute to such a number?
Is it OK if I just up and leave just about now?
I would seriously question the motives behind anyone asking such a question either of current or prospective employees. It is most likely the same type of company that would start doing code reviews focusing on the number of lines of code you type.
Now, if they argue that the number of lines of code is a measure of the experience of a programmer, then I would definitely leave the interview at that point.
Simple solutions can be found for complex problems, and are typically better than just throw enough lines of code at the problem and it'll sort itself out. Since the number of bugs produced scales linearly and above with the number of statements, I would say that the inverse is probably better, combined with the number of problems they've tackled.
As a test-response, I would ask this:
If in a program I am able to solve problem A, B and C in 1000 lines of code, and another programmer solves the same problems in 500 lines of code, which of us is the best (and the answer would be: not enough information to judge)
Now, if you still want to estimate the number of lines, I would simply start thinking about the projects the person has written, and compare their size with a known quantity. For instance, I have a class library that currently ranges about 130K lines of code, and I've written similar things in Delphi and other languages, plus some sizable application projects, so I would estimate that I have a good 10 million lines of code on my own at least. Is the number meaningful? Not in the slightest.
Sounds like this is D E Shaw's questionnaire?
This seems like one of those questions like 'How many ping-pong balls could you fit in a Boeing 747?' In that case, the questioner wants to see you demonstrate your problem solving skills more than know how many lines of code you've actually written. I would be careful not to respond with any criticism of the question, and instead honestly try to solve the problem ; )
Take a look at ohloh. The site shows metrics from open source projects.
The site estimates that 107,187 lines of code corresponds to an effort of 27 Person Years (4000 lines of code per year).
An example of the silliness of such a metric is that the number is from a project I've been toying with outside work during 2 years.
There are basically three ways of dealing with ridiculous requests for meaningless metrics.
Refuse to answer, challenging the questioner for their reasons and explaining why those reasons are silly.
Spending time gathering all the information you can, and calculating the answer to the best of your ability.
Making up a plausible answer, and moving on with as little emotional involvement possible in the stupidity as possible.
The first answers I see seem to be taking the first line. Think about whether you still want the job despite the stupidity of their demands. If the answer is still Yes, avoid number 1.
The second method would involve looking at your old code repositories from old projects.
In this case, I would go with the third way.
Multiply the number of years you have worked on a language by 200 work days per year, by 20 lines of code a day, and use that.
If you are claiming more than one language per year, apportion it out between them.
If you have been working more on analysis, design or management, drop the figure by three quarters.
If you have been working in a high-ceremony environment (defence, medicine), drop the figure by an order of magnitude.
If you have been working on an environment with particularly low ceremony, increase it by an order of magnitude.
Then put the stupidity behind you and get on with your life as quickly as possible
Depending on what they do with the answer, I don't think this is a bad question. For example, if a candidate puts JavaScript on their resume, I want to know how much JavaScript have they actually written. I may ask, for example, for the number of lines in the largest JavaScript project they've written. But I'm only looking for a sense of scale, not an actual number. Is it 10, 100, 1000, or 10,000 lines?
When I ask, I'll make very clear that I'm just looking for a crude number to gauge the size of the project. I hope the employer in the questioner's case is after the same.
It is an interesting metric to ask for considering you could write many many lines of bad code instead of writing just a few smart ones.
I can only assume they are considering more lines to be better than fewer. Would it be better to not plan at all and just start writing code, That would be a great way to write more lines of code, since at least if I do that I usually end up writing everything at least twice.
Smart of stack overflowers would generally avoid organization that ask this kind of question. Unless the correct answer is "huh, wtf??"
If you were to be truly honest then you'd say that you don't know because you have never viewed it as a valid metric. If the interviewer is a reasonable/rational person, then this is the answer they are looking for.
The only other option to saying you don't know is to guess, and that really isn't demonstrating problem solving skills.
Why bother calculating this metric without a good reason? And some random company asking for the metric really isn't a good reason.
If the company's question is actually serious, and you think the interview might lead to something interesting, then I would just pick a random number in order to see where that leads :-)
Ha, reminds me when I took over a C based testing framework, which started out as 20K+
lines that I ended up collapsing into 1K LOC by factoring down to a subroutine instead
of the 20K lines of diarrea code originally written by the original author. Unfortunately,
I got spanked harder for any errors in the code as my KLOC's written actually went
negative... I would think long and hard about shrinking the code base in a metrics driven organization....
Even if I agree with the majority in saying that this is not a really good metric, if it's a serious compmany, as you say, they may have their reasons to ask this.. This is what I would probably do:
Take one of your existing project, get the number of lines and divide it by the time it took you to code it. This will give you a kind of lines per hour metric. Then, try to estimate how many time you have worked with that specific language and multiply it with your already calculated metric. I honestly don't think it's a great way.. but honest, this isn't a great question neither.. I would also tell the company the strategy I used to come up with this number.. maybe, MAYBE, this is what they want.. to know your opinion about this question and how you would answered it? :p
Or, they just want to know if you have some experiences.. so, guess an impressive number and write it down :D
"This is a very respected company in its domain and I am sure they have some very good reason to ask this question"
And I am very sure they don't, because "being respected" does not mean "they do everything right", because this is certainly not right, or if it is, then it's at least dumb in my opinion.
What does count as "Lines of Code"? I estimate that I have written around 250.000 Lines of C# Code, possibly a lot more. The Problem? 95% was throwaway code, and not all was for learning. I still find myself writing a small 3-line program for the tenth time simply because it's easier to write those three lines again (and change a parameter) than go search for the existing ones.
Also, the lines of code means nothing. So I have two guys, one has written 20% more Lines that the other one, but those 20% more were unnecessary complicated lines, "loop-unrolling" and otherwise useless stuff that could have been refactored out.
So sorry, respected company or not: Asking for Lines of Code is a sure sign that they have no clue about measuring the efficiency of their programmers, which means they have to rely on stone-age techniques like measuring the LoC that are about as accurate as calendars in stone-age. Which means it's possibly a good place to work in if you like to slack off and inflate your Numbers every once in a while.
Okay, that was more a rant than an answer, but I really see absolutely no good reason for this number whatsoever.
And nobody has yet cited the Bill Atkinson -2000 lines story...
In my Friday afternoon (well, about one Friday per month) self-development exercises at work over the past year, tests, prototypes and infrastructure included, I've probably written about 5 kloc. However one project took an existing 25kloc C/C++ application and reimplemented it as 1100 lines of Erlang, and another took 15kloc of an existing C library and turned it into 1kloc of C++, so the net is severely negative. And the only reason I have those numbers was that I was looking to see how negative.
I know this is an old post, but this might be useful to someone anyway...
I recently moved on from a company I worked at for roughly 9.5 years as a Java developer. All our code was in CVS, then SVN, with Atlassian Fisheye providing a view into it.
When I left, Fisheye was reporting my personal, total LOC as +- 250,000. Here's the Fisheye description of its LOC metric, including the discussion on how each SVN user's personal LOC is calculated. Note the issues with branching and merging in SVN, and that LOC should usually only be based on TRUNK.
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.
When working on a project, after the interesting parts are coded, my motivation is severely diminished. What do you do to get over this problem?
Don't leave all the "boring" bits to the end - make sure that each component works, with regression tests and documentation, as early as possible in the project.
That said, the last few weeks are still going to involve chasing down the really elusive bugs, dealing with last-second requirements changes, finalising the documentation, and generally getting the damn thing out of the door. My approach is just to suck it up: put your head down and know that the sooner it's done, the sooner you can start on all the lower-priority, more interesting things that have been queued behind the current release.
You can't completely avoid last-minute requirements/docs changes other than by arranging for your customers to all be on holiday just before release. Or get yourself in a dominating position like Apple and Google, so that customers have no prior knowledge of releases.
You "should" chase elusive bugs (by which I mean the ones so hard to reproduce that you don't have a consistent test case) early, because you cannot estimate how long they will take to fix. But in practice some proportion of them will become less elusive as the project goes on, or turn out to be side-effects of another known issue, so you save time on average by giving them a limited chance to do so. The downside of this is that towards the end there will be a few left. If there are more than about two, though, you've done it wrong.
Taking a short "break" after a major deadline to do whatever you find most fun is a good way to avoid burn-out in the long run. Even if you end up throwing most of it away because you skipped some difficult planning, you'll have made yourself more productive.
Use test-driven development. A failing test is always a strong motivation.
Let some testers loose on it. Nothing is more motivating than seeing people use your interesting bits and finding obvious improvements.
Repeat to myself: My code doesn't exist until it is checked in.
Or if you're not using version control, 'until it is published' or 'until it is launched.'
You could also use fear and say that if YOU don't finish and launch it, someone else will.
Usually I try to tell myself that getting things to work in the real world is just as interesting, because there is where your code will get credits or will be improved by discovered bugs and feature requests.
Don't do all the interesting parts first.
I motivate myself to do the boring code by always leaving a decent bit until last and being strict about completing the boring section first.
"if YOU don't finish and launch it, someone else will."
Told myself that one before. Sometimes however its good to take a break for a couple hours then come back to it. Then you are not as burned out on it as you were.
I try to push the concept of bug days / evenings. Set a target of bugs/issues to address and when you hit that number everyone gets to go out for (paid for!) pizza/beers. Keeps the morale of the team up and acts as a focus in an otherwise boring period.
Also you can add into this concept prizes/cudos for the best piece of refactoring or performance improvement etc
I agree it is tough. The only thing that keeps me going is to keep in mind the feeling I would have after seeing it complete / shipped / in the hands of customers.
My motivation is just to Get It Done. Like onebyone said, you just have to hunker down and do it. It's all a matter of priorities. The quicker the priorities are out of the way, the sooner you can get back to the interesting stuff.
Try to see if you can take a very short break for a day or two and come back more refreshed.
Don't leave boring bits to the end
Test it yourself
Ensure that your diet/exercise/sleep/etc level don't get lower
Tell the others that you are feeling a bit down, can you swap areas of work for a day?
In general, when you've done 90% of the work, it's almost ended, you just have to do the last 90% :-)
Always think about that, and you'll see that's a long way until it's working.
I'm happy doing the creative fun bits of programming.
But after that I think about making the user happy.