
You Are Not Your Code (2012) - Tomte
http://sstephenson.us/posts/you-are-not-your-code
======
greymalik
More broadly, it’s an important emotional insight to realize that you are not
the product of your work. You are the insight and the knowledge and the
diligence and the intelligence that produced the work that was a good solution
to a particular problem that existed in a particular context at a particular
time. You are the person who did good work before and who can do it again.

------
alrs
If you replace 100 lines of my code with 20 lines, God bless you.

If you replace 100 lines of my code with 500 lines of buzzword-driven
development that is 50% copied off of Stackoverflow, we're going to have a
discussion.

~~~
johnchristopher
So, I recently (as in yesterday evening) converted the following piece of code
in index.php of a wordpress plugin:

    
    
        if( $_GET["foo"] == "bar" ) {
        //add_action( 'wp_loaded', 'do_foo' );
        //add_action( 'init', 'do_foo' );    
        //add_action( 'admin_init', 'do_foo' );
        do_foo();
        }
    

which allowed easy launching of do_foo() by simply httping
[http://wordpress.tld/?foor=bar](http://wordpress.tld/?foor=bar)

to

    
    
        add_action('rest_api_init', 'Company\PluginName\setup_foo_route');
    

and

    
    
        namespace Company\PluginName;
    
        function setup_foo_route()
        {
            register_rest_route(
                'company/v1',
                'bar',
                array(
                    'methods' => 'GET',
                    'callback' => 'Company\PluginName\do_foo',
                )
            );
        }
    

which can be run by httping
[http://wordpress.tld/?rest_route=/company/bar](http://wordpress.tld/?rest_route=/company/bar)

Which one of us would like to talk to :) ?

~~~
dahart
That’s perhaps much too small to be an example of what the parent comment was
talking about. This might be a good example of what the article is talking
about though. These represent two different fashions, both of which have
enjoyed widespread support at different times. The original is explicit and
smaller and easier for someone who’s not you to follow & modify. The latter is
event/callback driven, and more complicated to follow, but in a large codebase
might be a pattern that is easier to build on, maintain, and refactor, as well
as harder to screw up when adding new routes.

~~~
johnchristopher
I agree with you. What makes me lean towards my solution is that I can pass
the plate to the WordPress documentation if anyone else want to know what the
code is doing and we can follow the trail of callbacks and hooks while that
request check can be (and in this case, is) sprinkled all over the codebase.

What I noticed is that people following the first method ends up hacking core
functionalities of WP because "it just works" but in the end that makes the
code unstable and harder to maintain because it relies on undocumented stuff
and a coding style that is very personal. It can also messes big time with
stable things expected from the CMS (mangled taxonomies, hijacked hooks in the
core instead of the WP pile that make it hard to debug or to play nice with
other plugins/themes).

------
sqldba
I know how they feel. I often replace code and feel like it's attacking the
author; and also feel like my own code is being attacked when it's replaced.

~~~
afarrell
We should have some more common script for telling a colleague "that you for
writing this code. It has clarified the problem a lot." as we delete the code.

Its hard because while we do recognize that the value and difficulty is in the
problem-understanding, the code is the most tangible thing we produce and so
it feels like the work.

~~~
to11mtm
I think it goes both ways.

In every shop I work at, I do ask WHY someone refactored something I have
done. However, I do not do so with any malice.

As you point out above, sometimes, that first writeup is a working
implementation, and while important, the first iteration is often not optimal.

Thus, asking why is useful because it helps us become better developers.
Talking about the changes helps share knowledge, and, yes, when questionable
changes are made, it can be a lesson for the refactor-er as well.

And when I am the refactor-er... I will try to explain my changes in the PR.
Usually with a polite explanation of why I refactored.

------
karmakaze
> Browser vendors responded to the JavaScript renaissance by adding new APIs,
> many of which conflicted with Prototype’s implementation. And developers
> began to show a preference for small, self-contained, modular libraries over
> more monolithic frameworks.

I also find this very interesting. Many codebases decline in usage by not
being actively developed. Other times, changing the way things are done goes
against the core and is better off leaving it alone, and developing anew. Of
course this is only clearly visible in retrospect. I'm generally against
adapting to trends and wonder why perfectly complete and functioning
frameworks need to be actively developed. This is why--we want to know that
the framework will change with the users.

The second part of the trend to prefer modular libraries, I think was
transitional as there was no one framework that had the best of breed
components and using individual libraries produced a better ad-hoc framework.
Now we have something in-between with coherent frameworks but still having
replaceable parts.

------
oblib
Up until Prototype I'd purposely stayed away from Javascript. All my app code
was server side Perl. Prototype, for me, demonstrated the potential of JS and
made me want to look further into it.

I first used it to reduced the number of calls to my server by showing/hiding
sections of a form and that made my apps way easier to use and much faster for
the end user.

It was a little clunky (for me) to implement but it worked with most of the
web browsers at the time and that made those features available across
platforms. That was huge for me. I replaced it with jQuery later on and still
use jQuery.

I have to credit Sam Stephenson with showing us (or at least me) the way
towards full blown client side web apps. My latest version of that same app
runs entirely in the user's web browser on or offline. Prototype was the first
stepping stone I stood on to get here.

~~~
dwd
There are still 100s of thousands of Magento 1 sites still around that would
be using Prototype for core functions. Always fun trying to get the two to
play nicely together. I remember having to work with MooTools occasionally as
well before jQuery completely took over.

------
alexashka
The other piece to this is in matters of the heart and pride - the intent
behind it and the way it is done, oftentimes matters more than the outcome.

If someone goes about it the right way, the wrong decision in hindsight will
feel right at the moment in time. Human matters oftentimes require a delicate
touch, something that not many of us deeply involved in software pay attention
to :)

This applies in dealing with others but perhaps even more so in dealing with
yourself. If you don't tie your self worth to the work that you do, when the
tides of time make your work irrelevant, it won't be so painful.

------
swalladge
The conclusion to this article is really powerful. The distinction being made
is important - important to understand from both a user's and a developer's
perspective. Too often on both sides the line is blurred and discussions
around technical topics either get taken personally or become personal
attacks.

------
type0
Slightly tangential but it's good description about the problems that
Javascript still faces today.

------
dagnysdildo
So, we're supposed to take ownership of our work when it suits our bosses, and
alienate ourselves from our work when ownership is inconvenient to others?

