Senior means two things:
- Have experience
- Self learning though above experience.
I met many experienced developers, but most of them failed at step 2. To me, they're still junior.
- Have experience
- Self learning though above experience.
I met many experienced developers, but most of them failed at step 2. To me, they're still junior.
More than once I've proven my value as a senior engineer by refusing to do work that should be left to someone else. Sure I could figure it, but it would be a waste of time when someone else can. Sometimes because it is obviously an easy task, and thus good for a junior engineer to learn to figure things out on. Sometimes because it is something I'll never need again and I know we can hire a contractor who already knows how to do it.
Looking back, I accidentally turned my first full time into a senior position almost immediately
A local company gave this self-taught developer a chance as a glorified intern, but a few weeks in and I reimplemented a project they had given to a contractor in a weekend after overhearing their back and forth.
We ended up shipping my MDM on hardware across the country that Christmas, less than 3 weeks after that weekend project, and I spent the next 2 years extending it as a platform: completely driving the functionality that sales would then go and sell new clients on, designing and implementing an autoscaling analytics backend and frontend, embedded V8 so that client's engineers could script the product without mucking in my codebase about with source access ;)
I remember I got a 25k pay raise at one point by simply saying "I was thinking I'd make more once we got past the evaluation period"
I had actually been trying to ask for us to set up a performance review, but in retrospect they were probably terrified of losing this guy they were paying half a senior dev's salary to do 2x the work, and were ok paying 2 thirds of a senior dev's salary instead...
In some ways I feel like the work I did there was more senior than the work I do now, at least in a technical sense. I think it's the soft skills that come from experience
Show me a mid-level engineer and I will show you someone busy walking straight into a trap.
* also me sometimes, but that's confusing since I just used the commercial definition of the word a few comments above.
So I don't think it's an issue, if that's been your job. My job exposes me to a lot of different technologies: many programming languages and endless different software that might be supporting a web application (databases, webservers, firewalls, etc.). I consider my value to be looking at problem and being able to spot 10 different possible points of failure in a system in my mind and order them by priority based on likelihood and ease of troubleshooting. And this is something that I think is only gained through experience and that's what separates me from someone who just started.
I have long subscribed to "A programmer is not language specific", and I don't hire based on the languages you know. But that first task is "Here is access to the repo. Read and understand what our code does today please. I'll answer questions within reason." Acquiring the new language happens as a side effect.
Maybe six months if you're very good, but I'd wait a year before assigning a big project to someone new in a language/framework. Still wouldn't consider them a master with just one year of experience, mastery of a modern language can take years, you can always go deeper.
Learning a language and mastery are separate things. An actual experienced dev should be able to hit "competent" in any new language within weeks so long as it's within the same family of languages they've used in the past. Procedural languages, like C, are pretty much squarely in the middle of what everyone has learned unless by some fluke they started and continued with Haskell and similar languages and never touched any of: Go, Rust, C#, Java, Javascript, Lua, Python, Perl, Ada, Pascal, Fortran, Matlab, BASIC (various forms), and a hundred other languages.
As we all know, the subject of UB and the practical ramifications of particular instances is a topic few people could reasonably learn in weeks or even months.
You would probably not want someone with little experience in given language, to touch production codebase without review, because there are always traps that you might've not encountered in other languages.
I typically don't touch low-level programming languages, but once I had to use C to write some small adapter to communicate with some Oracle product. I did it, it worked as expected, but I would not be able to use it efficiently for complex solutions without more experience with creating and managing solutions in C.
I can also write in Go with some basic proficiency, I felt confident at one point in my abilities, but when my code got reviewed by someone specialized in Go, he would propose several improvements that did not cross my mind, because I had less experience in Go.
I never said otherwise. This is part of the distinction between competence and mastery. I would not expect most people to master a new language in just weeks, but a senior developer should be able to be competent within weeks. Now, would they have a product or substantive (non-trivial) change to show after those weeks? Maybe not, that might take a few more weeks, or longer if it's larger in scope.
> I can also write in Go with some basic proficiency, I felt confident at one point in my abilities, but when my code got reviewed by someone specialized in Go, he would propose several improvements that did not cross my mind, because I had less experience in Go.
That's part of learning, but it probably didn't take you a year to learn enough Go to get something in a reviewable (if not passing review) state.
I wouldn't want anyone, in any language, with any level experience to touch production codebase without review.
Not even K&R themselves.
So that's a ridiculous straw man.
Everyone makes mistakes. And code review is also about knowledge sharing and avoiding single points of failure in staffing.
This feels like a town cop enforcing strict speed limits in the couple of miles that fall in their jurisdiction. If K&R show up at your door and want to touch your production code, you just let them, bring them coffees, and ask for autographs. Even if it breaks, it would be an amazing story.
If you had 10 years of java, you can absolutely learn how to write Go in 3 days, unless your 10 years of java is "writing CRUD in Java 6 with libraries available in 2006".
The whole stack? Takes about a month to get productive and about three months to really internalize. Think interned strings in Python vs symbol exhaustion in Ruby. Or serializers in Django Rest Framework working as both input validators and output generators compared to stock Rails views.
Super similar languages with lots of similar frameworks and libraries, but they have these edge cases that still crop up.
Are you going to write elegant, idiomatic code in the first week? Of course not. But give the task "make the system do X", 90% of coding is knowing how computers work, and the other 10% is knowing how to search on stack overflow to be able to translate what you want to do into the desired syntax.
Idiomatic Go has some very large differences from idiomatic Java or PHP, including things like 1) the reliance on multiple return values and early exits for error handling 2) interfaces instead of inheritance 3) plain old data structures instead of everything-is-an-object 4) goroutines 5) table-driven testing 6) complete reliance on gofmt for formatting rather than doing it manually. And that's just the stuff that I'm aware of, as someone whose primary language is not Go but worked in it for about 3 months.
My definition of a senior dev would be someone who's aware that they can't just pick up a language in 3 days and write idiomatic good-quality code, but expects that they're going to have to keep learning for multiple years to really master a language. It's the metacognition of realizing how little you know and always continuing to learn.
The rest of it is learned (hopefully quickly) through the CRs, and any senior engineer should be comfortable making a few idiomatic mistakes in their CRs that they learn from.
Any engineer should be able to do this because the team has written good wikis and has working build tools, tests, etc
I could do all those setup things in N days without ever learning any programming language.
“3 days into the job”
I basically learned ideomatic go in a week, by skimming over the "effective go" guide and cross referencing concepts to other languages I know -- there is really nothing inherently 'new' in Go that would require years. It's a deliberately simple language.
We like to talk about how code is written, because we look at code all day. The rest of the world only cares about what your code does once it's compiled.
Senior engineers solve problems. They're not overly concerned with ticking all the boxes just so they can get a "good code" sticker.
While I do agree that many developers sometimes like to argue about "code quality" too much (and I've probably been guilty of that at times), "code quality" is definitely a real thing. I have have interacted with code bases that were a joy to read/modify, and I've interacted with code bases that made you pull your hair out at every turn (and also many levels in-between the extremes). It is not always a case of just "arguing for the sake of arguing".
But I strongly disagree with the sentiment that someone should not write code in a certain language, or should not contribute to a project until they know how to write idiomatically according to all the "accepted" best practices. It's a pedantic and elitist attitude which has little to do with making good software, and runs counter to the practice of learning how to use a language, which is necessarily a process involving ignorance, trial and error.
As a senior I can pretty quickly tell in the languages I write in often, when something is a smell, and if you keep repeating some code smells for a like a year you'll start seeing compounding effects on development speed. Understanding when to allow those with good reason and when to coach someone to stop doing those is an important skill for a senior imo.
But it's definitely not immediate, way more of a pernicious concern, the codebase will effectively rot until it's painful to make changes.
The point where this happens depends a lot on problem domain. If you're doing well-understood CRUD-screen database stuff but applying it to a novel business domain, you're probably not going to hit code quality issues. If you're doing heavy algorithmic, OS, financial, or networking stuff, though, where failures compound and any one bug might take the whole system down, you really want to pay up for experienced developers that have seen all the ways these systems can fail.
That said, I can really only speak to web api dev, data engineering and search. I'd say out of all of those search was the tightest area with regards to quality and even then I was lucky to be working with another very talented dev. Him and I didn't run into very many issues we were unable to solve with scaling the technology even after hitting 100m pages or so and we could have kept going on scale but we were cost constrained, navigating the business side was far more challenging for us.
I'll admit as well I've been pretty lucky so far to work in situations where code quality is considered and managed and haven't yet worked somewhere where the concerns were entirely ignored or the team didn't care.
People in your company (including non-engineers) definitely care, because code quality bears on how easy it is to debug problems and how easy it is to implement new features or fixes (or sometimes if a feature is even practicable).
He had spent the 20 years copying the same html file and changing the text for whatever was needed.
Struggled heavily with the concept of a loop.
Dream job right there.
Can also describe a complex single-page web application :-)
For a little annecdata - I've been a dev for 25 years, with a senior level (and above) title for about 80% of that, and I reckon I'd take at least a couple of months to get to a point where I was happy with golang. I guess that makes me a junior in your opinion. However, instead of being able to get up to speed with a language quickly I bring a fantastic level of respect for users, a talent for technical writing, a belief that documentation is actually important, a sense of fun and joy in making high quality software, and a deep understanding of browser-based software. If I was looking for a new team member I'd seek out someone a bit like myself rather than someone who can learn a new language faster.
This is, IMO, a hallmark of "senior" engineers and above. Much more important than language adoption/choice.
I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team. We are expected to deliver according to a plan while we keep hunting for relevant info.
I would say the second point is a lot more nuanced than stated.
This _could_ be true for some, but it directly conflicts with the stated goals of the language. Most people (that I've spoken to) would consider Go to be a simpler language, with fewer features, than other comparable languages.
Concurrency is tricky, and that is true in every language, but less so in Go.
Even those of that had it working, it was a huge time sink.
(asking because my own team is currently moving in this direction, and I'm curious about the pedagogical challenges we might face)
And Helm is just closing the cycle of Samsara - if you really want to base your operations on string templating, just use bash lol. Or hand-written forms on paper, still faster and you still get a better idea of what's going on.
There's also the problem of many developers nowadays just not having the hacker mindset/actual high-level abstract thinking/attention span, so instead of seeing the whole of K8S as the pointless kludge it is, they only see the interface - yay, YAML, I know that language! (usually they know it from everyone's favourite "dead" tool, docker-compose; which is a gem) - and they go on to fight with it tooth and nail, with corresponding feelings of "achievement" and "mastery".
I think the "10 years PHP/Java -> 3 days Go" thing from granduncle's cousin post is meant to point out this particular paradoxical situations.
But it could hurt people's feels to say it like that so let's just let Google do all our thinking for us instead. We truly live in a gilded age of computing.
I can't speak for Helm, but working with Kubernetes in Go is almost uniquely difficult. Kubernetes modules are designed to be dynamic, and Go's type system doesn't make that easy, which leads to some cludge-y code out of necessity.
Plus the API is vast, and it's sometimes not clear what package you need for a particular use.
golang is a language designed for fresh graduates to write fast code without much thinking. It isn't tough at all. For engineers that never worked with CSP paradigm, or rather for engineers who only ever work with Java style OOP and concurrency, it might be weird to adjust, and they will spend 3/4 of their time bitching about how much it is easier in language X.
- Y-yes...
- You are fire!
Note: Sorry for the cheap joke, I also make frequent grammatical errors in English.
In 3 days someone should be able to fix a small business logic bug in a program in a new language, like copy-pasting a if-block to handle a new simple case, or improving an error message by grabbing a variable from context and for setting it for output, but not write a useful program.