I am a mediocre developer | Hacker News Reader

I am a mediocre developer

dev.to

92 pointsjanvdberg63 comments

You can't possibly be a "mediocre developer" if you do all that mentioned in the article. I guess that was the joke :)

Re: "I google simplest things all the time", I once wrote my own regular expression parser, context free grammar parser, etc. in Lisp, Python, Perl, and JavaScript.

But to this day I still have to google javascript syntax to work with regular expression for certain things.

Memory is no longer a competitive advantage, the real competitive advantage is the ability and discipline to do everything OP talks about in the post

He uses good practices, but at the time he can be bad dev. Because programming isn't about variable naming and etc. It's about writing working algorithms and if you can't do this, then nobody cares how good you at not writing working things.

True, I just remembered there are too many developers nowadays just blindly focused on "best practice" so that they can be "seen as" a good developer, but the real good developers are the ones who actually come up with creative solutions to get things done and not always dogmatic about these things.

A good dev is one who knows when they write bad code, IMO.

If programming is really about writing algorithms then why people(both candidates and employers) complain about whiteboard interviews? I think that most of the programming done today are in fact declarative due to abundance of high-level languages frameworks, libraries and other great tools that abstract business logic away from the low level imperative instructions. Obviously it's good to know how everything works behind the scenes but I know many people who are far less familiar with the CS basics than me yet they are tremendously more productive in software development.

If all your work is to read/write data from DB and represent it in different ways, then yes, you can know absolutely nothing, use standard framework functions and be stackoverflow developer 8/5. But if you need to write something specific, something more complex, you can't just take two functions from your %framework_name% and make it beautiful and working. You should know how to do it and furthermore, you should know how to do it with existing tools. And here the majority begin to have problems.

Well, it really depends what do you mean by "something more complex". I remember when the author of rather non-trivial tool used by many of HN users went on Twitter rant because he could not invert a binary tree and failed a whiteboard interview https://news.ycombinator.com/item?id=9695102 To me, and possibly most CS freshmen, this task would be a piece of cake, yet I think Max is a better programmer than most of us - a.k.a. rockstar developer.

Something more complex is like audio/video codecs, image compression, etc. When they are developed, existing algorithms and libraries cover, at best, half of the needs. That's what I'm talking about. There almost isn't exist areas where you can use only existing code base and feel good with it.

I assume you're absolutely right about the areas you mentioned but it's not something that an average developer works on nowadays. In the same way as the majority of professional drivers are not race drivers.

Fraud detection, billing systems, infosec, banking, HFT, image/video processing and pattern recognition, games development, firmware, highload tools and services, tools for programmers (IDEs, linters, etc.), programming languages design, browsers, search systems, data processing and storage systems, electronic document management, cryptosystems, operating systems, frameworks, etc. It seems to me that this is a large part of the software being developed right now. And the development of all this requires rather non-trivial knowledge and skills. So your comparison with the race drivers is quite far from the truth.

I'm assuming you're in one of these fields and conveniently count yourself among the 'non-trivial' developers?

Yes, I am in one of this fields and no, I am "mediocre developer".

all the more baffling that you feel a need to go out of your way bucket your work into 'mediocrity'.

Honest question, when's the last time you had to do that.

Second honest question, did you have to do that, or did you do that because it was Not Invented Here?

Virtually no-one in our industry needs to write algos regularly. If you are, that probably means you're a bad programmer suffering from NIH syndrome. Or you're one of a tiny group who actually need to because you're doing something cutting edge.

It's shouldn't be cutting edge. There may be no open source library or commercial library for your needs (e.g. parsers for most telecom protocols). Your algorithms can be client specific. There may be only awful libraries especially if you use a language in an area for which it is not designed (e.g. something like C/C++ and Websockets). And there may be hundreds and thousands of other reasons. Of course, many people use Spring/Boost/etc. for routines like data transfer and popular protocols (JSON/XML) parsing, but it's only part of big picture.

As an ecommerce developer. Especially business specific stuff. Discount rules according to merchant, customized search aggregating other systems.

Most of the time is db stuff, sure. But it is always useful someone who can think and solve problems.

> If all your work is to read/write data from DB and represent it in different ways, then yes, you can know absolutely nothing, use standard framework functions and be stackoverflow developer 8/5.

Do you actually believe that's true? I can understand if this is just a knee-jerk comment that you haven't put thought into, but if it isn't that, I truly hate your kind of thinking.

While I'm not a fan of modern front-end programming, I do appreciate the sheer amount of knowledge and tedium involved in making that 'read/write DB operation' actually work in the context of the demands of modern front-end development, and I despise those who pretend it's trivial.

Is it different from the kind of knowledge necessary for picking the right algorithm? sure! Is it inferior (by whatever definition that self-servingly serves), and does it involve 'knowing nothing'? Far from it. Knowing what's necessary for a lot of front-end work is far from trivial, and while I dislike it, pretending it involves no knowledge or expertise is 100% pure bullshit.

I agree with you.

Let's imagine all you know is handling a full-featured framework like Rails or Django - while relatively mundane and boring I'd argue that alone turns you into a very capable developer who's able to make things happen without diving into rocket science.

Algorithms are not "what you learn in an algorithms course" and also not "what you are asked to do in a whiteboard interview". Writing an algorithm is what you do when you specify a way to mechanically obtain a solution to a problem, whether you do that in a declarative language or an imperative one or even in a language whose only interpreter is your own head.

Ok, if we stick to your definition of algorithm that it actually makes much more sense.

I disagree. Programming is about whatever the particular case is about. In some cases that can be about 'working algorithms', but in other cases it can be about building a CRUD app and knowing the nuances of front-end development concerns (including, sometimes, CSS quirks and the like).

I find many discussions about these issues tiresome because they feel like someone arguing that 'writing', in general, is about grammar, or vocabulary, or style, or whatnot. It's about all these things, and none of these things, depending on the context.

I think the concept is the same as Socrates's "The first step towards wisdom is recognizing your own ignorance".

Sounds like most developers, honestly.

I think about 5% of all developers out there nowadays are actually good developers. IME, most would have no idea what to do if you took away stackoverflow or their abstractions that make their day manageable.

A part of the problem might be that a lot I've met aren't at all interested in development, it's a job and they like the pay. They also just see it as a stepping stone to management.

When I do ask people at work how something actually works they rarely know. I get told just use 'x' it hides all that stuff away for you!

When I bring up basic concepts around coding, and therefore issues in their code, I get blank stares.

I mean, i've seen me having to explain to a C# dev with a few years experience why something like the following didn't work:

    string s = "foobar";
    s.Substring(1, 2);
    Console.WriteLine(s);

He didn't know strings were immutable, didn't know how to understand the documentation for Substring and had never heard of immutability.

Similarly, I've had to explain why something like the following prints 5 and not 6:

    void Main()
    {
        int x = 5;
        Foo(x);
        Console.WriteLine(x);
    }

     void Foo(int x) => x++;

A developer this time who had no idea about reference types & value types.

I don't know how we fix this though. As the people hiring and doing the interviews often don't know what they are doing either. So the blind hires the blind.

Were the people to whom you had to explain those concepts juniors or people with a couple of years of experience?

A few years experience (3+)

This is imho the difference between someone who graduated with a Bachelor (or higher) in computer science and somebody who completed a 3 month coding bootcamp.

Before people get upset, yes, there are devs without a degree that know what they are doing.

Absolutely, the building i work in does these coding bootcamps. Learn web dev in 8 weeks type thing, I can't believe anyone comes out of that knowing much about anything.

This is your occasional reminder that FizzBuzz was originally proposed because people with degrees -- even post-graduate degrees -- in CS were perceived as unable to code their way out of a paper bag.

I am having difficulty believing that someone wouldn't know how variables are scoped/refernced in function calls like the one you showed in the second example.

About the immutablity of strings : Is it absolutely necessary for a string to be immutable? What harm could it do otherwise? I learnt immutablity on my own and apprently there's no such constraint in languages like C/C++, although the same behaviour can be replicated using `const`.

I don't know C# but shouldn't `Console.WriteLine(s.Substring(1, 2));` have worked. No need to worry about immutability, at least in this case.

Strings being immutable in .NET is a good thing, for a few reasons. e.g. string pooling (less assembly bloat), string interning (performance) and performance in general.

You also get linq style benefits, e.g.

    string s = "this is a string";    
    if(s.Substring(5).ToUpperInvariant().StartsWith("I"))
        Console.WriteLine("true");
    Console.WriteLine(s);

If strings weren't immutable, you'd have to copy s to avoid changing / breaking it.

These are things that I would expect a .NET developer to know. They are basic fundamentals.

> performance in general.

Really? Forcing you to copy whenever you want to modify gives you worse performance.

> If strings weren't immutable, you'd have to copy s to avoid changing / breaking it.

That seems like a disadvantage to me. With mutable strings, you have the option to modify it in place instead of being forced to copy.

Ideally you have strings that can be both mutable and immutable based on context. C# is not that smart so they opted into the only other sane option.

The advantage of making the string type immutable is that you can do what's known as "string interning": if the same string shows up multiple times in your program, only one copy has to be kept in memory. This is particularly useful for compile-time constant strings.

C and C++ actually do a similar thing with their string literals, which are immutable even though normal strings aren't.

`Console.WriteLine(s.Substring(1, 2));` _would_ work. You'd be printing the new string returned by the Substring() call. But `s.Substring(1, 2);` as a statement on its own does nothing - its new returned string is discarded on the wind.

> I am having difficulty believing that someone wouldn't know how variables are scoped/refernced in function calls like the one you showed in the second example.

I strongly believe it, in fact, just as I'm writing this I'm not sure what a language like PHP would print out in that example (maybe the latest versions do the "right" thing, but back in PHP3 and PHP4 times variable scoping was a mess).

Interestingly the two examples work together: the "x" is passed to foo by value, so a copy is modified and then not returned. If you have _mutable_ strings then write

    void Main()
    {
        string s = "foobar";
        Foo(s);
        Console.WriteLine(s);
    }

     void Foo(string s) => s.Substring(1, 2);

then this example behaves differently from the x one. Unless you copy strings on function call, which is potentially more expensive.

You get the option to write C# code in an unsafe way, if you will (i.e modifying strings in place). Although i'v never needed to do such stuff when making line of business applications. https://www.codeproject.com/Articles/3377/Strings-UNDOCUMENT...

I'm a bit twiddler from way back - my first love was 65C02 assembly language in the mid 80s and my 2nd love as a professional was C for 12 years - but until I stopped considering myself as just someone concerned about code and learning how to efficiently deliver business value, my career suffered.

I take advantage of as many third party libraries and abstractions as possible. I try to use cloud solutions as much as possible (Lambda, RDS, SQS, etc.). In the market where I live, React/Angular + NodeJS jobs are a lot more plentiful and pay more than C jobs. Also, being able to leverage "abstractions" like AWS/Azure functionality is a lot more marketable than knowing how to setup everything yourself.

I'm the type of person that likes to learn deeply about my chosen platforms (C#, JavaScript, AWS,Mongo, SQL Server) just because I'm a geek, but the money comes from knowing high level architectural concepts.

I've had 5 jobs since 2012 and only once did I have a coding test (pair programming on a computer).

If you were any good you wouldn’t have 5 jobs in 5 years!

Since when changing jobs is an indicator of anything? This is not the time to spend 40 years in one company. So many people jump from company to company to feel the thrill and challenges which they currently do not have it does not mean that they burn bridges behind themselves or are bad at what they do. It's like climbing... but differently.

Exactly. I can get positive references from all of my past managers since 2008. Except for the Fortune 10 Company. I was just a number there.

Well, considering that one startup completely went out of business in 2011, let's say 4 by choice.

So 4 jobs since 2012. I was off by one. I make 45K more now than I made in 2012. Because salary compression is real, the easiest way to make substantially more is by job hopping.

I wasn't early in my career - but in 2008, I had stayed at a company too long and between measly raises and bonuses being cut, my salary was barely keeping up with cost of living.

I pivoted more to being a C# "Enterprise Developer", got a job paying a little more in 2008 as a junior C# developer. Learned a lot, that company folded at the end of 2011.

Next job was as a Mid level c#,web developer at major at the time Fortune 10 Company, learned how big companies worked and learned how large projects were managed.

Three years later, companies were offering 25K more for "senior developers" than I was making in 2012. With the combination of new skills and having a big company on my resume, it was fairly easy.

Two years later, I was applying for a job as an "architect" making another 13K more than I made in 2015.

Now startups are recruiting me, because I both have the experience and the technical knowledge as both a hands on coder and leading team.

One thing that saved my bacon is to write scripts that test production data is valid (for the few things that cannot be enforced by the DB, at least not easily).

Invariably, those scripts found invalid data, which pointed to hard to spot bugs. Catching those early saved me from having huge amounts of invalid data to manually sort through.

Do you want to give a quick example?

Sure, let's say you have an organization, in which you have users and devices, so users and devices have a nullable FK to organization. Also, a device can be linked to a user, so a device has a nullable FK to a user.

Now, when a device is linked to a user, both should be on the same organization, right? I don't see how to easily do that as a constraint (but I have to admit my SQL skills is quite low, and I avoid bypassing the ORM). Well, in production, devices might land somewhere else, and now you have a device that is supposed to be on organization A which is linked to a user on organization B, if you didn't force the organization when a device is linked to a user.

Depending on your use case, it could be expected, an operational error, or something that should be resolved automatically.

Edit: another example. We have a legacy system. Part of the data is supposed to be mirrored on both new and legacy system, via API calls (I don't know of a better way, I'm not a great dev, DB are different, not shared and on a different provider). Well, check if they are actually the same from time to time (at least the obvious stuff).

>Now, when a device is linked to a user, both should be on the same organization, right? I don't see how to easily do that as a constraint

I'm not exactly an expert when it comes to SQL either, but in this case wouldn't it be better if the "Device" table had two columns: "UserOwner" and "OrgOwner" which in turn have FK connections to "Users" and "Organizations".

If the logic is that every device is only owned by a user or an org (never both) at any time, you could constrain: check(UserOwner is null or OrgOwner is null).

Thats a great idea, run into a more than a few cases where production data is all sorts of messed up only after running migrations against it.

Not memorizing pointless shit (argument order, all function names, etc.) is actually a sign of a skilled developer who uses memory for important things, not things that can be looked up on Google in a second. Yes, if the Internet drops all productivity stops, but that's not because everyone needs to copy shit from stackoverflow every 2.5 seconds. Being able to develop without an Internet connection ... whoopty fucking do. Not impressive at all (unless you're trying to do well at a stupid whiteboarding interview) since without Internet, I'm pretty sure all work grinds to a halt and it's a ridiculous situation to prepare for. Why not code without computers (again, getting into the territory of beyond stupid interviewing here, the only place where this would be useful)? If you want to be a good developer, relying on memory and memorization for trivial things is a terrible use of your own inner resources as is trying to be productive in an environment without proper tools (no Internet / computer to work on).

Human memory doesn't work like your hard drive. The notion that you have some sort of 'free disk space', because you don't remember function names is ludicrous. Quite contrary, the more you train your memory, the more you can remember.

I didn't say it works like a hard drive. Yeah, the more I train, the more I remember what I trained and remembering function names and argument order is something I specifically don't want to do because I can only train my memory for so long each day and I'd rather remember important things, not trivial shit like that.

You know that before SO and Google all dev community was doing well? Using manuals and stuff that are typically on your machine from day one or from moment you install something you want to code in.

Now it is: No Internet = No Coding. Then: No Internet = Who needs this shit?!

I would argue that OP isn't mediocre if they accept their faults. I also search on SO a lot ("how to check for string prefix in PHP" or my favorite "php variable reference").

A good programmer is someone who can see the architecture of a program when given a high-level description of the problem. Someone who I can realistically tell "write me a program to backup my files" and will end up writing a reasonable backup system. Someone who I can task with coming up with an application protocol with certain constraints. In short, someone who can be an artist, engineer or scientist depending on what is needed.

Good practices are largely irrelevant to being a good developer, you can be a good dev writing spaghetti code and a bad dev using TDD and OOP.

I'd kill to be mediocre. Being a bad developer is my pinnacle achievement.

This blog post has the paradoxal property that the act of writing seems to immediately contradict it. This person does not seem mediocre. He's humble, that goes a long way.

Good tooling can save you a lot of googling mentioned here. Your editor should tell you the required order of arguments, for example.

I'm not even a mediocre developer, since I'm just a hobbyist, but I have found it extremely helpful to invest the time and just sit down with a printed out 'cheat sheet' and learn standard library functions and standard packages and their functions by heart. Just recently did it with peewee.

Do you feel this significantly speeds up development?

I've always found this a pointless exercise since I can get the answer I need with a quick Google search. After working with a language or library for some time, most of these things become muscle memory.

Rather than making a conscious effort to remember all of these things, I let my brain unconsciously decide what's important enough to remember.

I think it does. Not because I save the time of the Google search, but I can apply the functions and methods without distraction. Sure, a quick websearch is nothing that really holds you back in terms of time spent, but it opens a new tab in your browser and your brain and will divert your attention away from solving the actual problem you are working on.

A mix of the two approaches might yield the best results.

At work I usually go by looking for quick solutions for the very specific problems I encounter, e.g. disable echo on a terminal, send data through a socket, ...

And what I sometimes do over the weekend is to go over the problems I had and try to learn from the subject in a more generic way. e.g. learn TTY inner workings by reading the source code of python's pty.py standard library module, read the socket's documentation and understand all available socket operations, or watch some conference talk on the subject over youtube ...

This second consolidation phase has proven very useful to me. Not only because of discovering interesting gems hidden in standard libraries and other references, but also to be able to anticipate and solve really weird/low-level bugs that otherwise would have been very difficult to approach.

If you have a cheat sheet on your desk, why do you also have to memorize it?

To keep a clean desk.

A great keynote by Jacob Kaplan-Moss at PyCon 2015 along similar lines: https://www.youtube.com/watch?v=hIJdFxYlEKE

As a more mediocre developer than the author, I would add that instead of copy-pasting code, you actually type it out. This makes it stick better for me.

Reply on news.ycombinator.com