
What is difference between scripter and developer? - archlight
<p><pre><code>    Recently I went to an interview for python developer. I didn&#x27;t get the job and when I asked for feedback, they said it seems I am more like scripter. 
    I can write codes under framework and abstract business logic on top of libraries. When I look at my works, They seem to solve a lot of things but design is a bit flat. Usually I am alone doing project. It makes me quite hands on. However the bad part is I think I know it but each time I just take easy path which might not be best practice. 
    I think really hope to leap from scripter to developer. maybe working in a team helps. any advice is welcomed. Thanks!</code></pre>
======
zer00eyz
I just see this as a lame non answer. When being asked for why I'm passing on
someone I can give some fairly clear and concrete reasons. What someone could
have done differently or what skills they could have had that would have
pushed them over the top.

My questions for you: do you know more than one language? Can you design a
database "from scratch" \- do you understand the rest of the technology in the
stack of your domain - (servers/network and so on)?

> Recently I went to an interview for python developer.

This tells me a lot because the python community is, for lack of a better
word, weird. There are plenty of (ab)users of python who get shit done without
being programers by trade. I can point to plenty of data, EE and systems admin
folks who see python as a swiss army knife. Their code is ugly but functional,
it isn't code that is going to scale or be elegant, rather it serves a
purpose. Python on the web/api side is a different beast, it is easy to turn
your python code into a big ball of mud without a fair bit of discipline -
Exactly what that takes is up for some debate and can be domain dependent.

If your the sort of python dev who focuses more on "get shit done" rather than
"long view" I could see how someone might make the comment they did. The get
it done mentality is not something you need to drop all together (it happens
to be how I use python myself) but it doesn't preclude you taking the long
view as well.

Lastly you can run into some very odd camps/elements in the python community -
the fact that were 9 or 10 years into the 2.x to 3.x should tell you where
some of the lines might fall.

~~~
archlight
I belongs to get-shit-done camp. It is so easy to check if someone has
packaged a module for you. like if mongo call is blocking in tornado, i don't
wrap it with coroutine. simple search i found motor/tornado redis/etc. only
during debug, occasionally I jump in their codes and get idea how they do it.
but that is only out of curiosity.

my work doesn't have collaboration other than users. if they want realtime
feed, i do quick meteor app just a bit more complex than quick starter
tutorial. I really want to break into serious development

------
bulatb
The very short version:

Probably ignore that person.

The short version:

Reading charitably, what they meant is that they're looking for people with
open-ended problem-solving skills. They're confident in your ability to, as
you say, solve specific problems whose form is well understood: writing a
controller, connecting APIs, and so on. What they're more concerned about is
whether, if you had to, you could reproduce that API or write that framework
from scratch, design and all.

In other words, they're looking for a person whose skill is "fix a broken
car," not "fix the power steering on a 2015 Honda Civic." Maybe they don't
have a Honda Civic. :)

The oops-not-long version:

Though it's possible to make a technical distinction between programming and
"scripting," people who insist on making it are often doing that for social
reasons (which is why I jumped to probably ignore them). I don't know if going
into detail would be helpful, so I'll actually stop there.

~~~
archlight
I see people who has CS background like to talk about performance, go deep
into the subject. the common question asked how python list implemented. I
reply variable array and interviewer is happy. To be honest i haven't noticed
list has to resize when appending more items. probably i haven't seen real
world problem.

I think there is some special code unknown to outside developer league that
they can test and know you are real developer

------
xstartup
I don't agree with the scripter vs developer differentiation.

But my interpretation of the difference is that

Some developers can read the documentation, put together what some devs might
deem easy like build REST API, put on a rate limit, add authorization,
integration with payment APIs, scrape website or parse CSV file etc... This is
what 80% of the job involves.

Some jobs include requirements like this

Build a distributed key-value store for storing counters, it must work for
1200 RPS, the counts must be available in both EU and US region (150ms) apart.
Counters should be consistent in both the regions.

Can you think through such problem? Do you know what it takes? Do you know
updating counter is not a single operation but:

1\. Read the original value 2\. Increment the value 3\. Save the new value

Do you know how latency the between the region affects the throughput of the
service? How can you make counters reflect consistent count in both regions
consistent?

What if one of the servers goes down? How do you make it highly available?

Customers might increase and we end up needing more nodes. When are more nodes
added how is the data rebalanced, what effect does it have on throughput and
latency?

~~~
archlight
I met one asking are you package users or know the underhood.

Your interpretation is well said. I am doing that 80% stuff. it seems to
deliver a lot and feel like developers currently I am writing very defensive
codes which not addressing problem directly. I just want to get it done
quickly.

------
twunde
The main difference is whether they think that you'll write maintainable code
and extensible code. Will teammates be able to work with your code easily?
Will others be able to maintain or extend the code when you're gone? Is it
easy to debug? Does your code use the right abstractions when appropriate? Is
your code efficient? The response probably indicates that they saw something
in your code that they felt wasn't up to par.

In general, this is something that you'll improve at naturally when you work
on teams or maintain legacy code (assuming a relatively good codebase). One
thing that can be super-helpful is to review a good codebase and see how
features are implemented and think about why it was done this way and how you
would have done it (for python, take a look at the flask or django codebase
and see how they use abstractions). And honestly keep interviewing.

~~~
archlight
Thank you for your advice. The problem with my current job is I am one man
team building tools for less than 20 users. I am not using Jenkins. usually I
check out codes from servers and simply copied in share drive. They only saw
code snippets in codepad. I think the way I talked doesn't seem like I am
working in a professional team.

I have never worked in a team, doing peer coding/review. It is good to have
this practice so people feel you are in their league. and usually through
teamwork you get questioned and spot your area for improvement. I am kind of
doing this through interview but that is really waste of opportunity this way.

