work flow 
Author Message
 work flow

guys, as Im still reletively new to php (and programming in general), I was
wondering, on just your average, run of the mill  day of coding..how
productive do you pros tend to be..I mean..do you code and debug 500-1000
lines of code a day, or more?  Do you guys keep 1 browser window open at the

syntax well enough to work without the docs being open)?

I know that this is a really akward, generic question, Im just trying to
scale my self and see if Im ready to leave my current job(chrysler mechanic)
and actually get a job in the web field.

Any feedback would be appreciated
thnx

--

CMosser



Sun, 26 Jun 2005 22:22:50 GMT  
 work flow

Quote:

> guys, as Im still reletively new to php (and programming in general), I
> was
> wondering, on just your average, run of the mill  day of coding..how
> productive do you pros tend to be..I mean..do you code and debug 500-1000
> lines of code a day, or more?  Do you guys keep 1 browser window open at

> the syntax well enough to work without the docs being open)?
<snip>
> Any feedback would be appreciated

Lines-per-hour used to be a pretty standard (and, arguably, even
appropriate) metric for programmer productivity but, in all honesty, it
doesn't mean much these days. It depends almost entirely on the tools used,
the language proficiency, programmer experience, etc. On a good day i may
pump out 80+ lines per hour (by hand) in PHP, Java, Perl, C++ or shell
code, but this depends largely on:

a) How well i know the topic i am coding for. For example, i can code
database abstraction layers and classloaders in PHP 50x faster than i can
code the same in C++, because the PHP language is so friendly for that sort
of thing. Likewise, writing a generic classloader in C++ would take me a
lot longer because i don't know much at all about how to find symbols
inside of .so files, etc.

b) The available tools. i'm fortunate enough to have an employer who lets us
choose our own tools, so i'm happy and productive. If i was stuck with
WinNT 4.0 and it's lame excuse for a shell i'd be probably only 1/3rd as
productive (i use the shell a lot even when coding PHP). (i'm {*filter*}ing from
experience there, yes.) By the same token, if i've got a single Good
browser then i can be much more productive than if i have to keep swapping
between 3 different browsers to check everything (as was the case even just
1 year ago under Linux).

c) Being an obsessive coder i will sometimes sit and play with 20 lines of
code for a half-hour to figure out how to squeeze it into 10 lines. Ooops!
There goes my lines/hour count!

My point being, lines per hour don't mean much except in very specific
contexts. A good coder can do more in 3 lines than a newbie can in 6 lines.
A great example of this is the following function (from Java, but the
principal is the same):
public static
  java.util.Calendar
  getMaxOfThreeDates( java.util.Calendar d1,
                      java.util.Calendar d2,
                      java.util.Calendar d3 )
    {
        return d1.after(d2) ? (d1.after(d3) ? d1 : d3) : (d2.after(d3) ? d2
: d3);
    }

Your average newbie would solve that problem with several if/else blocks and
it would be 10-15 times longer (but no less correct than the above
solution!), so lines of code don't mean too terribly much. In all honesty,
i wrote the above function first with if/else and then re-did it simply
because i found if/else to be an unimpressive, uninspired solution. i code
as much for the joy of coding as i do for the end result of a running
program, and that definately impacts my lines/hour in a negative sense.

Another example:
The management has decided that class Foo has to be renamed to Bar across
your whole project tree, spanning over 1000 files in 3 different languages.
For a newbie this may seem like a large amount of work. For a proficient
shell user (which most Unix programmers are, i think) it's potentially one
command line - about 15 seconds of typing. If i change 304 lines in less
than 1/2 minute from the shell is that 600 lines per minute of coding? If
not, why not? If so, how do i realistically justify my speed to the
management? The answer, i think, is to Not think in terms of lines/hour.

Point being: don't put much weight on lines/hour. They're not objectively
quantifiable across the board - they depend very, very much on the exact
context.

--
----- stephan beal
Registered Linux User #71917 http://www.*-*-*.com/
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.



Sun, 26 Jun 2005 22:57:10 GMT  
 work flow


Quote:
> Do you guys keep 1 browser window open at the

> syntax well enough to work without the docs being open)?

I download the compiled help edition of the documentation. Then you don't
need to be connected to the net to look up references.

http://weblabor.hu/php-doc-chm/

Even if you are familiar with the syntax the user comments are still very
helpful.



Mon, 27 Jun 2005 04:56:52 GMT  
 work flow
Raw lines of code per hour is no measure of productivity. Working,
tested modules of code are. This is much harder thing to achieve and
takes diligence as well as skill. You need to develop solid testing code
to test each module so that it can be used with confidence in a larger
system. This makes it much easier to isolate and correct faults also.

Productivity is also a function of how well the system has been
designed, and how well you, the programmer, understand it. Ideally you
have played a key role in that design, so coding should flow easily from
it. Poorly designed systems, or more frequently, systems that are coded
without any design effort at all, can end up coding themselves into a
hole in the ground. Prototyping like this is fine, and is useful to
discover the best ways of doing things, but is bad way to code the final
system.

If you want to compare yourself to other programmers, compare programs
you've written with other programs you consider to be of value. If your
code is as robust and functional, then you can say you are the equal to
the programmers who developed these systems. You should also compare
your coding style with well-written examples. How readable is your code?
Is it well commented? Are the functions small and self contained? This
may sound pedandic, but it's the sort of thing any good software shop
will insist upon. Sooner or later you will end up maintaining your own
code, possibly years away. It is then that you will appreciate the
effort you put in today to make it understandable.

I wish you all the best. Give it a go!

Steve

Quote:

> guys, as Im still reletively new to php (and programming in general), I was
> wondering, on just your average, run of the mill  day of coding..how
> productive do you pros tend to be..I mean..do you code and debug 500-1000
> lines of code a day, or more?  Do you guys keep 1 browser window open at the

> syntax well enough to work without the docs being open)?

> I know that this is a really akward, generic question, Im just trying to
> scale my self and see if Im ready to leave my current job(chrysler mechanic)
> and actually get a job in the web field.

> Any feedback would be appreciated
> thnx

> --

> CMosser



Mon, 27 Jun 2005 16:58:49 GMT  
 work flow
That's so true: I agree completely with what Stephen said about not
working in lines/hour, and about productivity being different
depending upon what you're working on.  A bit time spent understanding
the project (and not actually coding) can easily prevent spending
hours unpicking code down the line because you've misunderstood the
requirements / capabilities.

As for tools; I use a whole variety.  I started off, and still largely
use, a shell-based or windows-based text editor.  These days I tend to
do a lot of writing in a Windows based editor (Textpad) and upload
stuff, then make tweaks via a shell-based editor (my favourite is
"ee").  If you can get direct access to the webserver (ie save
directly to it if it's on your LAN), it can save a lot of time sending
files around the place.

At work I use Zend Studio, and can save directly to one of our test
servers (which is set up with the Zend debugging module).  Zend Studio
is very good at syntax highlighting, documentation generation,
tooltip-style context popups etc, and when coupled with the debugging
module it can save some time when working on a complex project.  The
debugging isn't the best thing since sliced bread though; I find
proper organisation of code, sensible naming of variables etc makes
fault-finding (and fault-avoidance) much easier than a debugging
system.  Still, it's nice to have available for those hard-to-find
errors :)

As for browser windows, my personal favourite is to have two monitors
on my computer.  I tend to have the editor filling one monitor, and a
few browser windows in the other (one with the script in question on
it, and another with the PHP docs or some other documentation on it).

In summary, it's entirely up to you.  If you're starting out, then
just try some scripts, find your feet, get inspired, and take it from
there.



Mon, 27 Jun 2005 08:54:42 GMT  
 work flow


Quote:
>guys, as Im still reletively new to php (and programming in general), I was
>wondering, on just your average, run of the mill  day of coding..how
>productive do you pros tend to be..I mean..do you code and debug 500-1000
>lines of code a day, or more?  Do you guys keep 1 browser window open at the

>syntax well enough to work without the docs being open)?

>I know that this is a really akward, generic question, Im just trying to
>scale my self and see if Im ready to leave my current job(chrysler mechanic)
>and actually get a job in the web field.

The magic productivity formula is skill + tools.

I spent the last two years (off and on) building a web-based authoring
tool (I wanted to be able to work from anywhere) for creating
database-driven web sites, primarily PHP/MySQL. The tool lets me
create 50-100,000 lines (many hundreds of files) of bug-free "base
code" (from scratch) in a day.

At the urging of a graphic designer friend of mine, I'm going to make
the tool public some time in the next few weeks. I'll keep you posted,
and all are welcome to take a peek.

-Ray



Mon, 27 Jun 2005 11:51:24 GMT  
 work flow
thnx alot guys..I appreciate the feedback

--

CMosser



Mon, 27 Jun 2005 11:52:24 GMT  
 work flow

Quote:

> Is it well commented?

Curiously, some projects don't LIKE comments in their code! Don't ask me why
(i comment like mad). i got a bit of a reprimand about this when i
submitted a few patches to the ANT project.

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.



Mon, 27 Jun 2005 17:57:00 GMT  
 work flow

Quote:


>>Is it well commented?

> Curiously, some projects don't LIKE comments in their code! Don't ask me why
> (i comment like mad). i got a bit of a reprimand about this when i
> submitted a few patches to the ANT project.

There is a difference between comments that describe non-obvious things
(like design details) and the more usual comments that are little pieces
of the PHP manual copied all throughout the code (to save having to look
in the PHP manual next time, presumably).  Heavy commenting was required
when programming languages had very short variable names; modern
languages like PHP can utilize long variable names to allow writing
sentence-like "self-commenting" code.

Phil



Mon, 27 Jun 2005 19:08:03 GMT  
 work flow

Quote:



>>> Is it well commented?

>> Curiously, some projects don't LIKE comments in their code! Don't ask
>> me why (i comment like mad). i got a bit of a reprimand about this
>> when i submitted a few patches to the ANT project.

> There is a difference between comments that describe non-obvious things
> (like design details) and the more usual comments that are little pieces
> of the PHP manual copied all throughout the code (to save having to look
> in the PHP manual next time, presumably).  Heavy commenting was required
> when programming languages had very short variable names; modern
> languages like PHP can utilize long variable names to allow writing
> sentence-like "self-commenting" code.

> Phil

"self-commenting code" is an oxymoron.

You can do with few comments if you use wise variable names (long ones
can help obfuscate your code) and a clean programming style. As a
minimum I comment each function simply describing what it does, what
each of the arguments is and what it returns.

Excessive comments can be a little bad in interpretted languages, such
as Javascript, where they also add to the overall size of the HTML
document. Some organisations may view commenting code such as Javascript
as a good way to give away "trade secrets". But a better approach would
be to simply strip them off before being served to the client.



Tue, 28 Jun 2005 07:18:45 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Data Flow not working in LabView !!!!!!!

2. Jobs, Jobs, Jobs, Work, Work, Work

3. Flow Layout Flaw? - rightSample.vu (1/1)

4. View Composer + Flow Layout

5. JCL flow chart

6. Smalltalk syntax and flow control

7. Program Flow Control

8. program flow control

9. text flow script?

10. Tools to Develop Flow Charts

11. SPIN - Continuos flow low to high to low

12. Api Call to detect web flow

 

 
Powered by phpBB® Forum Software