8 ms·
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
by revskill 4y ago
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.
- roflyear 4y agoCan you give an example of a failure at step 2?
- revskill 4y agoA 10 years Java/PHP developer doesn't know how to use Golang on the job in 3 days.
- abhishekjha 4y agoWell, golang is a tough language. 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.
- treeman79 4y agoSaw a company fail because all developers were expected to master k8/helm etc. A couple of us got the hang of it well enough to get by. But almost everyone failed too. Even those of that had it working, it was a huge time sink.
- funklute 4y agoIn what way were the developers expected to "master" k8/helm? In the sense of actually making contributions to the k8/helm setup, or simply using an existing k8/helm setup to provide a development environment? Was there any "expert" person on the team that everyone could ask about k8, or was everyone simply supposed to pick things up on their own? (asking because my own team is currently moving in this direction, and I'm curious about the pedagogical challenges we might face)
- robertlagrant 4y agoAnyone who is either insecure about their own skills, or so proud of their skills in their area that they can't face being a beginner in another area, will struggle and come up with reasons not to learn it. And they'll tell their nontechnical colleagues or managers that the idea is overengineered, or they'd add more value elsewhere, until it happens or they leave.
- kuramitropolis 4y agoIma be facetious here and suggest that the above is meant in the sense that K8 is the ultimate leaky abstraction and you have to "master" it first before even starting starting to achieve anything with it. 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.
- skohan 4y agoThat's why I'm a huge fan of server-less. Let Amazon or Google handle the tough parts until your company is big enough to have to optimize for server costs.
- Sholmesy 4y ago> Well, golang is a tough language. 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.
- Gwypaas 4y agoThe issue with Go is the implicit footguns you will inevitably hit. Starting out with Go sure feels like a super power because of the simplicity and productivity, until the code base has grown and you now meticulously inspect every single line to understand the entire context a change is bringing, because you do not trust it in isolation to be correct. https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/
- lupire 4y agoYou use Golang as a replacement for many Baah and Python programs, and never touch concurrency. Concurrency is tricky, and that is true in every language, but less so in Go.
- ASalazarMX 4y agoPython is also an easy to learn language, and you'll likely make correct programs quickly. Idiomatic Python, though, is a longer road. You won't feel confident to open source your code for months.
- everforward 4y ago> I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team. 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.
- 0x457 4y ago> Well, golang is a tough language. 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.
- macintux 4y agoNot everyone learns at the same pace, not everyone is great at bootstrapping.
- kilbuz 4y agoWhy is 3 days, likely with competing priorities, a reasonable timeframe to learn a new language well enough to contribute production code in your estimation?
- tikhonj 4y agoThe trick is that Go isn't a new language, it's an old language with a new coat of paint.
- nostrademons 4y ago3 days to learn how to write syntactically-valid Go or 3 days to learn how to write idiomatic Go? 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.
- skohan 4y ago"code quality" is not real, it's just something software engineers like to argue about like sports. 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.
- nocman 4y ago> "code quality" is not real, it's just something software engineers like to argue about like sports. 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".
- adamsmith143 4y agoI learned it in 2 hours so you are pathetically junior compared to me.
- neon_electro 4y agoThe real 10x engineer right here!
- ASalazarMX 4y agoI suspect he learned it in the future.
- Existenceblinks 4y agoI can figure out its internal AST once I stare at the lang's codes. \s
- treeman79 4y agoHad a guy with 20 years experience at a top mail carrier come in for a senior position. We were very excited to interview him. 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.
- trey-jones 4y agoI would never fault someone for not being able to pick up a language and use it competently in 3 days. I understand why you use this as an example, with having samey syntax, but there is still nuance. I think the bigger indicator is you've been in the industry for 10 years and call yourself a PHP/Java dev. At this point you should have dabbled in probably 10-100 ways of solving problems depending on what your 9-5 looks like.
- peteradio 4y agoWho said you need competence, looks like that was your own insertion, haha. But seriously is it not unreasonable to be able to write some non-deep dive code in a new but similar language in just a few days? 3 days is a long time to read and ask questions.
- trey-jones 4y agoWhat purpose does it serve though? I think being able to read and understand a Go program is a better example. That does seem like a reasonable and useful ask in 3 days for a veteran PHP/Java dev, and something that is more likely to come up in practice. What is the context of the former? "Welcome to our team. I know we didn't hire you as a Go dev. You have 3 days to "be able to write Go". 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.
- pantojax45 4y agoIf you hire someone in a language they don’t know, you expect them to learn on the job. It’s reasonable by day 3 to expect them to show some code - even if terrible.
- macintux 4y agoAt some companies you’re still in onboarding hell on day 3.
- onion2k 4y agoIn other words you're inventing some silly criteria that I'd guess you'd pass that others wouldn't. What I would say to that is that if you dismiss someone else's experience because they can't do some task you think they should be able to do rather than understanding that their experience probably brings something else to the team then that's your failing, not theirs. 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.
- rco8786 4y ago> a talent for technical writing, a belief that documentation is actually important This is, IMO, a hallmark of "senior" engineers and above. Much more important than language adoption/choice.
- claytongulick 4y agoAlso importantly, it sounds like you would bring the understanding that surface level productivity is not the same thing as mastery.
- 3pt14159 4y agoEh—I don't know. Code a test or two and something basic with just the lang? Sure. 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.
- metadaemon 4y agoA better example might be not learning from past mistakes, or asking the same question multiple times, even if framed in a different context.
- agumonkey 4y agoFor a bugfix or a whole new module ?
- rr888 4y ago"Use" is pretty vague. Can run the process and make a small fix should be easy. Writing idiomatic code in a new language takes months.
- Existenceblinks 4y agoI'd give them 1 week. And measure again at starting of week 3, if they are still struggle, that's very likely they suck at learning.
- ASalazarMX 4y ago- Are you still struggle?! - Y-yes... - You are fire! Note: Sorry for the cheap joke, I also make frequent grammatical errors in English.
- Existenceblinks 4y agoUsually, they will appoint a cold room for 1-1 meeting to hear what's going on. And find out whether it's hiring process or teaching process that's the problem.
- lupire 4y agoif they are still struggling on the same thing
- lupire 4y agoYou've spawned a silly thread, because mastering a language is a spectrum that takes years. 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.
- Existenceblinks 4y agoMy friends who won't step 2 mostly because they are limited by their circle's culture. There is this large enterprise corp network that can keep you stable forever, these guys never see outside world so global maxima is not a thing.
- ironmagma 4y agoI think you can be senior without experience. To me, senior means "can handle ambiguous/incorrect/incomplete problem definitions."
- jahewson 4y agoNo, you have you know the traps and specifically you have to know your own biases and this only comes with failure, thus experience. Show me a mid-level engineer and I will show you someone busy walking straight into a trap.
- ironmagma 4y agoWhen commercial hiring managers say "experience" though, they don't count school projects, volunteer (OSS) projects, or career-adjacent projects. That is the source of dissonance. You are right, it's just that you* vs. the managers have different definitions of the word. * also me sometimes, but that's confusing since I just used the commercial definition of the word a few comments above.
- omreaderhn 4y agoThis skill comes from experience. If you're talking about experience in a particular subdomain, then yes for sure.
- ironmagma 4y agoThe trick is, what people refer to "experience" in the workplace is very strictly defined as workplace experience in your role. But you can get experience from a wide variety of tasks, even ones that don't involve your current career. Working with vendors to organize a convention can prepare you for writing software. Or a volunteer/school software project could prepare you for a paid role, but nevertheless it is not counted.
- BoorishBears 4y agoI learned how to program starting on calculators in middle school and eventually moving up to games. 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
- PLenz 4y agoThe difference between 10 years of experience and 1 year of experience 10 times
- layer8 4y agoI would reformulate #2 as learning to figure out things on your own, i.e. not to bail out as soon as something is outside of what you’re familiar with. The ability to go one level deeper to find out how things work under the hood. The ability and interest to extend your horizon, to pick out the learning material you need for familiarizing yourself with something new, without needing it to be served on a plate by someone else.
- bluGill 4y agoThat is only half of #2. The other half is knowing when to bail early. 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.
- layer8 4y agoI would put “knowing when to bail early” on the “experience” side, so #1.