What is difference between scripter and developer? | Hacker News Reader

What is difference between scripter and developer?

8 pointsarchlight8 comments

    Recently I went to an interview for python developer. I didn'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!

View on HN

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.

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

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.

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

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?

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.

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.

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.

Reply on news.ycombinator.com