16 ms·

What I learned working with a senior engineer as a new grad

160 points by antidnan 4y ago

fake-name 4y ago
> senior engineer > been a professional engineer for 6 years Man, the software world is just weird.
- dom96 4y ago
  There are senior engineers out there that have <4 years professional experience. I myself went from IC3 (junior) to IC5 (senior) at FB in around 3 years and this is pretty common at FB from what I've seen.
  - kasey_junk 4y ago
    I think the concern is that the industry, including Facebook, has decided that the designation “senior” is a thing you can get in <5 years. It’s a norm in software so it’s easy to see examples of it, and in practice who cares what the titles were if they are used consistently. But what if you were outside the industry and heard that term? A senior judge typically has decades under their belt. A senior chief petty officer is the second highest non-commissioned rank in the navy implying a whole career behind them. They might infer it only takes three years of experience to reach the near top of the software craft.
    - polio 4y ago
      It feels similar to the title bloat of Goldman Sachs, where a lot of people are Vice Presidents.
      - kasey_junk 4y ago
        In certain regulated or audited environments you’ll see rules like “only a person at the VP level or higher can make decision xyz”. It’s just as stupid but there is a different reason for it.
    - joshuamorton 4y ago
      > A senior judge typically has decades under their belt. A senior judge is also quite literally a semi-retirement role. You take on reduced workload. > But what if you were outside the industry and heard that term? "Senior Associates" in the legal profession are junior/mid roles, similarly, senior account managers etc. aren't particularly senior in most places. In white collar roles, a "senior" is really just a distinction of independence and reliability.
- thom 4y ago
  I suspect 'Senior' most places just means 'more senior than at least one other person'.
- Cwizard 4y ago
  I’ve worked with some consultants that were ‘senior’ after 2-3 years of experience. I think there are two reasons for this trend: giving some a senior title can sometimes mean you have to pay them less (paradoxically perhaps) because they feel they are more important now, second consultancy agencies can ask higher rates for ‘seniors’.
- mierz00 4y ago
  Is it really that weird? In the military 6 years is definitely considered senior and I’m sure that’s also the case in a lot of other fields.
  - fake-name 4y ago
    I know the EE & ME worlds, senior generally implies at least two decades of experience. I'm pretty sure the same is also true for civil engineering, and most of the other "hard" engineering practices. It seems like (at least outside of the military) the duration to being senior and the importance of things not going wrong are correlated.
    - ReadTheLicense 4y ago
      The meaning is different. In software industry, senior means "doesn't need handholding", not "super-super-long experience" as in other more traditional fields.
      - pjmlp 4y ago
        I expect more than that, a senior should be in the position of accomplishing a task based on a ruff abstract, they should also be able to mentor juniors and jump into meetings with the customer, supporting architects and sales, if needed.
    - tiahura 4y ago
  - BerislavLopac 4y ago
    I think a part of this issue is that there is nothing above senior. Additionally, "seniority" is relative and can vary between different technologies: for example, I have been working as a software engineer for 25+ years, and while I have worked with Java before I am no better at it than someone who just graduated. Similarly, even though I spent nearly a decade as a frontend dev, the last time I did that professionally was in mid-aughts, and I have zero experience with React, TypeScript and other modern staples of that area.
- mudrockbestgirl 4y ago
  Easy to be a senior frontend engineer. Just say you were already around when the current most hyped JS framework was released that everyone must move to, 1-2 years ago.
  - ReadTheLicense 4y ago
    You mean like React (9 years ago), Angular (12 years ago) or Vue (8 years ago)? Who seriously uses anything else? I think you confused the JS ecosystem with the C# one.
    - tester756 4y ago
      >I think you confused the JS ecosystem with the C# one. What do you mean?
    - jaywalk 4y ago
      Angular will turn 6 years old next month. You're thinking of AngularJS, which despite the (unfortunately) similar name and parent, is basically a completely different framework. Although I don't see why you're bashing C#. Despite the .NET Framework > .NET Core > .NET transitions, it's not really that different. There's a ton of new functionality and ways to do things, but for the most part the old ways still work too.
- neilv 4y ago
  For software developers, I've thought 5 years of solid work and continuous learning is about the right time horizon for a senior title, in a typical contemporary software/internet company. (At least, 5 years of seeing the lifecycle through awhile -- not job-hopping repeatedly, before getting to see cause and effect together.) I could even see that going faster than 5 years, especially in a startup. For example, say one of your early hires is fresh out of school, but really curious and learning fast, already did some open source, learns from mentoring/osmosis, takes easily to a team sensibility, and has to tackle a lot of things like is the norm in a startup. Within a couple years, as the startup is starting to think about titles more, they might be a battle-scarred veteran with firsthand experience and maturity beyond their years. (Or, even if not everything is yet the complete senior package -- such as maybe they've only worked on one system and team, and could've overlearned from limited data points -- you want to acknowledge the value of their contributions, as well as their institutional memory and cultural role. So maybe help them level up any aspect they haven't yet had a chance to.) (BTW, I avoid the term "professional engineer" when talking about software, because I've heard it have special meaning in the more regulated, traditional engineering disciplines.)
  - zero_shift 4y ago
    I absolutely cannot agree with this. It's true that after five years in a startup, you'll have seen lots of systems. But being a senior practitioner requires deep experience as well as breadth, and enough time in the industry to recognise larger trends. There is no magic mark for this, and it's quite possible to reach ten years and still be a weak practitioner, because you were exposed to a narrow range of problems and were never around to see your bad decisions bear bad fruit. However, the opposite does not hold. It doesn't matter how intelligent you are, you can't short circuit repeated experience and the mix of breadth and depth required. People want to. I wanted to. But I didn't: all I became was an overbearing mid who had the rhetoric (and the OSS contributions!) to convince others I knew what I was doing. There is absolutely no comparison between myself in 2017 and myself in 2022, but we both have a job title of "Senior Engineer". In fact, I think that in the long term the trend is for the senior bar to get _higher_. This is pushed by two things: firstly, that the technical domain gets harder, software becomes more abstract, our expectation of engineers increases particularly in "left shifted" environments where every IC must do everything from frontend to microservices to infra to security to testing. The second force is demographic: as IC salaries have increased, there has been less pressure for senior engineers to exit in favour of the management track. That means more experienced engineers on average. Industry needs a way to describe these practitioners, beyond "very senior", and overall the range of skills of ICs will widen. Under those conditions the definition of senior engineer gets more exclusive, not less.
- nhoughto 4y ago
  Maybe I'm the outlier but at >15 years into this job I think back on what I was like/did/thought 6 years in and shudder, at that point I never mentored anyone my junior seriously enough to influence their perception (I don't think) but if I did I'm not sure it would have been a positive influence. The lack of failures, felt pain, time to reflect.. in combination with the hubris of 20-smth youth isn't a recipe for good software engineering I don't think.
- lopkeny12ko 4y ago
  Yeah, I stopped reading after this line. Sorry, but if you call yourself "senior" with 6 years of experience you've lost all credibility in my book.
  - wink 4y ago
    The author said that, we don't know if the mentioned person does it.
  - throwaway4233 4y ago
    Seniority is the fact or state of being older or higher in rank or status than someone else. Within an organisation, a senior engineer could be the engineer with the most experience with the codebase everyone else is working on. I do agree that certain habits or experience from working for additional years might be missing, but as the first engineer of a codebase, IMO, there will always be something to learn from them. Which makes the article credible enough to warrant a read.
  - pcthrowaway 4y ago
    Years of professional experience isn't a great metric of time steeped in software practices. There's a difference between someone who did a bootcamp and worked for 6 years compared to someone who started contributing to open source software at the age of 12, studied computer science, and then went into the industry. The latter might be more experienced at 1 year than the boot camp grad at 6 years.
  - runevault 4y ago
    I wouldn't instantly go that far. There are people who can be senior in 6 years. People truly that good are the exception, not the rule though.
  - MikeTheRocker 4y ago
    Much of the most widely used software in the world comes out of mid 20s so-called Senior Engineers in Silicon Valley (and other major US metros). Gatekeeping on the basis of years of experience is naive and unproductive. IMO "senior" is a function of behavior not time. At FAANG, levels are formally defined by traits. For example, a senior engineer can plan and lead 6-12 month long projects, delegating some parts of the implementation to others where appropriate. I personally was fulfilling this definition at 25 and I know several dozen others in similar situations.
- tiahura 4y ago
anotherhue 4y ago
No content with Javascript disabled. Hardly unheard of among a technical audience.
- tanishqkanc 4y ago
  Ah! That’s unfortunate . All that work of pre-rendering, and it won’t even work with javascript disabled. To be clear, I use a very very tiny bit of javascript only to animate the article elements after render.I guess when that fails, it just doesn’t animate the opacity to 1…hm...
  - ChadNauseam 4y ago
    Haha, same thing was pointed out to me when my site was posted to HN. My advice: use a css transition instead of js
    - tanishqkanc 4y ago
      Im not sure if there’s a good way to use css to animate an arbitrary number of children with a delay, while retaining clean markup. I did this before: .article-child { animation-delay: var(—index)*0.025s; } and while rendering, set style tags on each element style=“—index:5”, etc. That works, but it was annoying to maintain, and every single element has these style tags. So I just use Motion One (WAAPI) now.
      - pwg 4y ago
        Drop the animation and just let the browser render the elements and css position/style them. Most 'animations' on otherwise textual articles are merely eye-candy fluff that is totally unnecessary. PS: Viewing with JS on -- yes, totally unnecessary eye-candy fluff in that animation.
        tanishqkanc 4y ago
        But that’s my vibe!
samsquire 4y ago
Clean code is code you and others can understand and everybody seems to have a different idea of that. Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete. I don't think I would enjoy working on this codebase.
- zelphirkalt 4y ago
  Naming things is hard. Often when names are very long, they could be shortened, because they are in a function, which already narrows down the context and makes a shorter name still understandable. Very long names can also sometimes be a code smell, if they are relating to a lot of global state, which is not narrowed down in context by where it is defined. Sometimes however, it is really difficult to come up with a shorter name. I think it is definitely a skill, that takes practice and never is really perfected.
- lukeramsden 4y ago
  The point is to always name your variables / methods / classes as exactly what they do (not how they do it, but what they achieve). If this name looks ridiculous, like `doXAndYAndZAndSideEffect`, then your code is likely poorly factored. I've found it works very well for helping to find good separation of concerns.
- thraxil 4y ago
  The recommendation I read back in the 90's in Code Complete that has served me well ever since was that variable name length should be roughly proportional to the variable span. "Variable span" being the distance between where the variable is first defined and its last use. Generally that means that a temp variable inside a short function can be a single letter since you can see the full context of its entire lifecycle right there and it's unlikely to be confusing; indeed, a short variable name in that case will often be much easier to read and work with than a longer one. OTOH, a global or exported variable that might be accessed in different files from where it is defined or used across thousands of lines really needs to be descriptive enough that anyone encountering it should know what it's for without having to backtrack to where it was defined. A variable name that's a few words long might be entirely appropriate for that. A corollary is that a large variable span is often an indicator of a bad design. So if you find that you need really long variable names to make your code easy to understand, you might want to step back and see if you could set up some better or different boundaries. I've found this to be a much better rule of thumb than "always use long variable names" or "always use short variable names".
james420 4y ago
the takes in this thread are the worst
motoboi 4y ago
I have never given much attention to functional programming just out of prejudice. Now I read this blog and my head just exploded in the functional part. It's beautiful. What good introductions to functional can you people point me to? Also, good code is like prose. You write to other to read, and you need to guide their minds. Of course you can write in dense, truncated and clever ways, but your audience will be small (even yourself won't like your own prose 6 months from now). Good software is delightful to read.
- kabes 4y ago
  What part are you referring to? I don't see any FP stuff in that article... It's all imperative code? Anyway I would recommend learning Haskell. I like languages that allow different styles (like js does to a certain extent). But I think it's better to learn a modtly pure OO language like java and a pure FP language like Haskell to be able to make the right decisions in a language that supports both like JS.
  - remram 4y ago
    The author refers to it as "declarative programming" when they talk about functional programming. I would link to the section "Functional, declarative programming" but there are no anchors. The table of contents (which the author calls a "minimap") is not clickable either.
- antipurist 4y ago
  > What good introductions to functional can you people point me to? When people hear "functional programming" many of them will immediately point you to Haskell (and totally forget to mention The Haskell Pyramid [1]). I'd advise you to stay away from it until you _want_ to go deeper down the rabbit hole. Play with Elm and Erlang ("Programming Erlang" [2] and "Erlang Programming" [3] books are great) to un-learn imperative patterns, tinker with OCaml to learn a new way to modularize code. [1] https://patrickmn.com/software/the-haskell-pyramid/ https://patrickmn.com/software/the-haskell-pyramid/ [2] https://www.amazon.com/dp/193778553X https://www.amazon.com/dp/193778553X [3] https://www.amazon.com/dp/0596518188 https://www.amazon.com/dp/0596518188
dataflow 4y ago
Just a note that functional programming here seems to be conflated with declarative programming. They do have some things in common ("no mutable state" being the main one I can recall), and technically I think FP is categorized as a subset of DP, but in reality a declarative program ends up looking quite different from a functional program, so it's with distinguishing the two. To give a trivial example to illustrate the conceptual difference: a declarative program could say something like "the output is the solution to f(x) = 0", defining f explicitly and leaving it to the compiler/interpreter to supply the algorithm for figuring out an x that satisfies it. Note that, as long as x is unique, "try all legal values of x" works, so a viable fallback algorithm always exists; it's just inefficient. Whereas with FP you actually have to supply an explicit function to (hopefully efficiently) compute the output, i.e. you basically have to write f^-1 yourself, which typically results in a very different program - sometimes harder to read, sometimes easier. Now, of course, you could do "FP" by writing f instead of f^-1 and then enumerating all possible inputs as with DP, just as you could write a DP to compute functions explicitly at every step, and you could write imperative programs for all these. But those would be unnatural, and would generally defeat the advantages of the paradigms.
yodsanklai 4y ago
I've noticed many of these articles about what it takes to be a good software engineer talk about code quality. I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. Generally, there's very little bikeshedding on code quality and that kind of things. People are pragmatic and wants to get the work done. It also means there are trade-offs regarding code quality (also dictated by management and pressure to deliver). The challenges are elsewhere. Prioritising, communication, relationships with colleagues, setting up roadmaps and milestones, proposing designs, solving various challenges. Generally, I found software engineering is less and less about writing code. I'm impressed how my colleagues are good at everything. Fluent in most programming paradigms, able to debug complex production issues, do low level performance analysis and so on...
- pjmlp 4y ago
  Make it work, then make it pretty. Undelivered pretty code doesn't deliver any business value. Same applies to 100% code coverage that isn't running on customers computers.
  - karmicthreat 4y ago
    There are a ton of people at all levels that don't get this.
    - cainxinth 4y ago
      I think it was Judd Apatow who said “You have to give yourself permission for the first draft to be shit.” The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.
      - dinosaurdynasty 4y ago
tanishqkanc 4y ago
Hi! I’m the creator of the post. Thank you for all the comments on my post! I’m glad more people are getting to see it. Thanks for posting, @antidnan! Reading through, it looks like I have some rough edges of my website to clean up as well...
- scary-size 4y ago
  I enjoyed reading your blog post. It was very well written. Most of your points resonate with me.
  - tanishqkanc 4y ago
    Thanks!
- sergiosgc 4y ago
  Congratulations on the post. One may agree or disagree with the content, but the text is clear, to the point, and generally very well written. Good writing is, to me, the foundation of a good engineer. I know excellent engineers who are not great verbal communicators, but every excellent engineer I know writes like you do. I think it is the result of a structured thought process, that flows naturally into a structured clear text.
  - tanishqkanc 4y ago
    Thank you so much! I’m so glad it gave off that impression. I went through a lot of revision and planning to write it: I had learned a lot, and wanted to organize all of it carefully. I’m glad it paid off!
- antidnan 4y ago
  Hope you didn't mind me posting it! I was reading through the parser you posted yesterday and stumbled onto your blog :)
  - tanishqkanc 4y ago
yotamoron 4y ago
6 years of experience does not make one a senior engineer. I`ll be polite and say that most engineers with 6 years of experience I know are not seniors.
- yotamoron 4y ago
  So, just to make myself clear - there are very talented engineers with just a few years of experience, however that's the extreme exception. As pointed here, it is rare to work on interesting and trail blazing stuff - that's why it takes time, sometimes years, to gain the experience. There's a low probability of actually working on something meaningful, therefore you have to fight it with repeated attempts of finding the interesting stuff - and that takes time. Obviously, time is not the only thing needed to become a really experienced engineer, but - in almost all cases - its a prerequisite.
- jrockway 4y ago
  I think there's a split in the industry; outside of FAANG senior means "certain amount of time spent in front of the computer getting paid", inside FAANG, it's a set of behaviors encapsulated in a particular mid-career job title.
  - grayclhn 4y ago
    Inside FAANG, it is literally a job title.
    - dionidium 4y ago
      "Senior engineer" is a job title at every place I've ever worked.
    - jrockway 4y ago
      Yes, very good point. I added a little edit to clarify that.
  - twic 4y ago
    Outside of FAANG, senior means "we can't pay as much as FAANG but we will call you senior when you have two years of experience and no idea what you're doing".
dchapp 4y ago
> Long verbose names don't cost anything They absolutely do have a cost. The question is whether the benefit they bring in implicit documentation is worth their cost. > Even beyond the DX of readable names, it also acts like a type-checker. By reading the code, you can verify at least the semantics make sense. I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name.
- __Parfait__ 4y ago
  What's the cost?
  - dchapp 4y ago
    Readability. In particular, an increase in the rate at which long, verbose names which are mostly the same are confused with one another.
- shepherdjerred 4y ago
  > I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name. Have you never worked in a dynamically typed language?
  - dchapp 4y ago
    I have. I prefer statically typed languages.
  - plonk 4y ago
    Python is only palatable with strict type checking everywhere. I don't see how unchecked dynamic typing can bring anything else than chaos in a large project.
- nnnnico 4y ago
Nimitz14 4y ago
I think the lessons learned are exactly those you should be as a junior, nice post.
confidantlake 4y ago
The passionate arguments about what a senior is or isn't seems strange to me. Who cares if someone is junior, senior, jedi, ninja whatever. Using senior to distinguish between someone who just started and someone who has been there for a while seems perfectly fine.
- plaguepilled 4y ago
  Agreed. Title worship isn't helpful. Perhaps a qualifier would have avoided this whole issue, eg "my more senior teammate" or "my mentor". Then again, this seems like a reader issue, not an author issue. The salient point was never that Chet had status X and therefore could teach skills Y, it just was that Chet taught skills Y.
Retr0id 4y ago
I would be very interested to read an article titled "What I learned as a senior engineer working with a new grad".
smm11 4y ago
Been in the field more-or-less since the late 80s. There are days, weeks really, when I can't tell you what I've done. The business just chugs along. If I'm gone a day, though, my phone will ring by 10 a.m.
- AnimalMuppet 4y ago
  Bjarne Stroustrup said "It is essentially impossible to judge a programmer on the basis of only one year's work."
pca006132 4y ago
I don't think 'type unsafe' is the only way to enable decoupling. For adding new commands, it can be done in a pretty type safe way. The problem is that the `ICommandHandler` may be used in a lot of places expecting different parameters, so they try to simplify the interface by using `any` as the parameter type. > Static typing is really a form of testing No! Static typing is not a form of testing. Static typing or static analysis, is an approximation of you program behavior, because it is undecidable in general. Depending on the properties of the type system, you can guarantee that you program doesn't go wrong if it is well-typed, where the definition of 'go wrong' depends on the type system. On the contrary, testing can check the behavior of your program with respect to a set of inputs, and it doesn't guarantee anything outside that set of input. You are doing state partitioning by doing a static analysis over your code to determine what tests you may need, and test some of them.
adregan 4y ago
If I may pick on one piece of advice here: intermediate variables. I think both the bad and good examples are both equally unreadable and feel the "good" version would introduce more confusion into a code base than the "bad" example. For example, if I came across the example in code, I would begin to wonder why the `deltaX` variable exists at all if its only purpose is to be renamed `translateX` and spend some time tracing the code to see where the variable falls out of scope and to see if it's important. Then I might wonder whether it used for something else at some other point in time and trace the history of these lines (somewhat akin to nerd sniping). Now I'm focusing on the variable as if it's important when really the important bit is the relationship of the current to the initial. The code is obscuring the fact that "delta" is `current - initial`. Look how many times the pattern is repeated! Perhaps we need an abstraction that can produce the delta for us. However, the data structure makes that a little bit tricky as scrollTop is held in an ad hoc manner, so maybe we should update the data structure so that we can eventually have an api like: type ScreenPoint = { x: number; y: number; scrollTop: number } type toDelta = (current: ScreenPoint, initial: ScreenPoint) => ScreenPoint // example implementation of toDelta using ramda for brevity const toDelta = R.mergeWith<ScreenPoint, ScreenPoint>(R.subtract) const delta = toDelta(current, initial) shadow.style.transform = `translate(${delta.x}px, ${delta.y + delta.scrollTop}px)` Intermediate variables can be tricky because you can't always trust that the name matches what's actually going on inside, so you have to read everything anyhow.
- svnpenn 4y ago
  > using ramda for brevity please don't do that. Unless the article also uses Ramda (it doesn't) its not really appropriate for you to do so. If you want to use Ramda in your own, personal code, go ahead. But if you're posting a public example for other people to look at, including Ramda only makes sense if you're on a Ramda forum. The whole point of this article is clarity in programming, you've reduced that with you decision to include some obscure package.
  - adregan 4y ago
    It was only intended to be illustrative of thinking about the operation as merging two identical data structures in a manner that produces the result. You could accomplish the it using any technique your codebase prefers be it FP, OOP, &c. (some languages might even handle such an operation natively). In this case, I felt that it was sufficiently close to pseudo code “merge these objects by subtracting identical keys left to right,” but I understand your objection to obscurity. I actually feel that the implementation in this example is fairly unimportant.
pramodbiligiri 4y ago
Two of the points in the article are at cross purposes. The author mentions doing Mindful Practice but later says to be Problem Oriented. The first one implies a background thread making judgments that is constantly running in the back of your mind. The second needs you to ignore everything but the problem at hand. I’d go with the latter, esp if you’re new to the job. Let judgments accrue over time rather than go looking for them in the middle of a task at hand.
pojzon 4y ago
I find it hilarious the fresh grad with 6 months experience that doesnt know how to use git properly calls himself a “fullstack developer”. JS dev is a state of mind it seems.
mriet 4y ago
Sorry, but how the @#€& is 6 years a senior engineer? I consider all of the lessons that he mentions to be things that junior engineers learn before becoming medior engineers.
black_13 4y ago

160 points by antidnan 4y ago

fake-name 4y ago

> senior engineer > been a professional engineer for 6 years Man, the software world is just weird.

dom96 4y ago
There are senior engineers out there that have <4 years professional experience. I myself went from IC3 (junior) to IC5 (senior) at FB in around 3 years and this is pretty common at FB from what I've seen.
- kasey_junk 4y ago
  I think the concern is that the industry, including Facebook, has decided that the designation “senior” is a thing you can get in <5 years. It’s a norm in software so it’s easy to see examples of it, and in practice who cares what the titles were if they are used consistently. But what if you were outside the industry and heard that term? A senior judge typically has decades under their belt. A senior chief petty officer is the second highest non-commissioned rank in the navy implying a whole career behind them. They might infer it only takes three years of experience to reach the near top of the software craft.
  - polio 4y ago
    It feels similar to the title bloat of Goldman Sachs, where a lot of people are Vice Presidents.
    - kasey_junk 4y ago
      In certain regulated or audited environments you’ll see rules like “only a person at the VP level or higher can make decision xyz”. It’s just as stupid but there is a different reason for it.
  - joshuamorton 4y ago
    > A senior judge typically has decades under their belt. A senior judge is also quite literally a semi-retirement role. You take on reduced workload. > But what if you were outside the industry and heard that term? "Senior Associates" in the legal profession are junior/mid roles, similarly, senior account managers etc. aren't particularly senior in most places. In white collar roles, a "senior" is really just a distinction of independence and reliability.
thom 4y ago
I suspect 'Senior' most places just means 'more senior than at least one other person'.
Cwizard 4y ago
I’ve worked with some consultants that were ‘senior’ after 2-3 years of experience. I think there are two reasons for this trend: giving some a senior title can sometimes mean you have to pay them less (paradoxically perhaps) because they feel they are more important now, second consultancy agencies can ask higher rates for ‘seniors’.
mierz00 4y ago
Is it really that weird? In the military 6 years is definitely considered senior and I’m sure that’s also the case in a lot of other fields.
- fake-name 4y ago
  I know the EE & ME worlds, senior generally implies at least two decades of experience. I'm pretty sure the same is also true for civil engineering, and most of the other "hard" engineering practices. It seems like (at least outside of the military) the duration to being senior and the importance of things not going wrong are correlated.
  - ReadTheLicense 4y ago
    The meaning is different. In software industry, senior means "doesn't need handholding", not "super-super-long experience" as in other more traditional fields.
    - pjmlp 4y ago
      I expect more than that, a senior should be in the position of accomplishing a task based on a ruff abstract, they should also be able to mentor juniors and jump into meetings with the customer, supporting architects and sales, if needed.
  - tiahura 4y ago
- BerislavLopac 4y ago
  I think a part of this issue is that there is nothing above senior. Additionally, "seniority" is relative and can vary between different technologies: for example, I have been working as a software engineer for 25+ years, and while I have worked with Java before I am no better at it than someone who just graduated. Similarly, even though I spent nearly a decade as a frontend dev, the last time I did that professionally was in mid-aughts, and I have zero experience with React, TypeScript and other modern staples of that area.
mudrockbestgirl 4y ago
Easy to be a senior frontend engineer. Just say you were already around when the current most hyped JS framework was released that everyone must move to, 1-2 years ago.
- ReadTheLicense 4y ago
  You mean like React (9 years ago), Angular (12 years ago) or Vue (8 years ago)? Who seriously uses anything else? I think you confused the JS ecosystem with the C# one.
  - tester756 4y ago
    >I think you confused the JS ecosystem with the C# one. What do you mean?
  - jaywalk 4y ago
    Angular will turn 6 years old next month. You're thinking of AngularJS, which despite the (unfortunately) similar name and parent, is basically a completely different framework. Although I don't see why you're bashing C#. Despite the .NET Framework > .NET Core > .NET transitions, it's not really that different. There's a ton of new functionality and ways to do things, but for the most part the old ways still work too.
neilv 4y ago
For software developers, I've thought 5 years of solid work and continuous learning is about the right time horizon for a senior title, in a typical contemporary software/internet company. (At least, 5 years of seeing the lifecycle through awhile -- not job-hopping repeatedly, before getting to see cause and effect together.) I could even see that going faster than 5 years, especially in a startup. For example, say one of your early hires is fresh out of school, but really curious and learning fast, already did some open source, learns from mentoring/osmosis, takes easily to a team sensibility, and has to tackle a lot of things like is the norm in a startup. Within a couple years, as the startup is starting to think about titles more, they might be a battle-scarred veteran with firsthand experience and maturity beyond their years. (Or, even if not everything is yet the complete senior package -- such as maybe they've only worked on one system and team, and could've overlearned from limited data points -- you want to acknowledge the value of their contributions, as well as their institutional memory and cultural role. So maybe help them level up any aspect they haven't yet had a chance to.) (BTW, I avoid the term "professional engineer" when talking about software, because I've heard it have special meaning in the more regulated, traditional engineering disciplines.)
- zero_shift 4y ago
  I absolutely cannot agree with this. It's true that after five years in a startup, you'll have seen lots of systems. But being a senior practitioner requires deep experience as well as breadth, and enough time in the industry to recognise larger trends. There is no magic mark for this, and it's quite possible to reach ten years and still be a weak practitioner, because you were exposed to a narrow range of problems and were never around to see your bad decisions bear bad fruit. However, the opposite does not hold. It doesn't matter how intelligent you are, you can't short circuit repeated experience and the mix of breadth and depth required. People want to. I wanted to. But I didn't: all I became was an overbearing mid who had the rhetoric (and the OSS contributions!) to convince others I knew what I was doing. There is absolutely no comparison between myself in 2017 and myself in 2022, but we both have a job title of "Senior Engineer". In fact, I think that in the long term the trend is for the senior bar to get _higher_. This is pushed by two things: firstly, that the technical domain gets harder, software becomes more abstract, our expectation of engineers increases particularly in "left shifted" environments where every IC must do everything from frontend to microservices to infra to security to testing. The second force is demographic: as IC salaries have increased, there has been less pressure for senior engineers to exit in favour of the management track. That means more experienced engineers on average. Industry needs a way to describe these practitioners, beyond "very senior", and overall the range of skills of ICs will widen. Under those conditions the definition of senior engineer gets more exclusive, not less.
nhoughto 4y ago
Maybe I'm the outlier but at >15 years into this job I think back on what I was like/did/thought 6 years in and shudder, at that point I never mentored anyone my junior seriously enough to influence their perception (I don't think) but if I did I'm not sure it would have been a positive influence. The lack of failures, felt pain, time to reflect.. in combination with the hubris of 20-smth youth isn't a recipe for good software engineering I don't think.
lopkeny12ko 4y ago
Yeah, I stopped reading after this line. Sorry, but if you call yourself "senior" with 6 years of experience you've lost all credibility in my book.
- wink 4y ago
  The author said that, we don't know if the mentioned person does it.
- throwaway4233 4y ago
  Seniority is the fact or state of being older or higher in rank or status than someone else. Within an organisation, a senior engineer could be the engineer with the most experience with the codebase everyone else is working on. I do agree that certain habits or experience from working for additional years might be missing, but as the first engineer of a codebase, IMO, there will always be something to learn from them. Which makes the article credible enough to warrant a read.
- pcthrowaway 4y ago
  Years of professional experience isn't a great metric of time steeped in software practices. There's a difference between someone who did a bootcamp and worked for 6 years compared to someone who started contributing to open source software at the age of 12, studied computer science, and then went into the industry. The latter might be more experienced at 1 year than the boot camp grad at 6 years.
- runevault 4y ago
  I wouldn't instantly go that far. There are people who can be senior in 6 years. People truly that good are the exception, not the rule though.
- MikeTheRocker 4y ago
  Much of the most widely used software in the world comes out of mid 20s so-called Senior Engineers in Silicon Valley (and other major US metros). Gatekeeping on the basis of years of experience is naive and unproductive. IMO "senior" is a function of behavior not time. At FAANG, levels are formally defined by traits. For example, a senior engineer can plan and lead 6-12 month long projects, delegating some parts of the implementation to others where appropriate. I personally was fulfilling this definition at 25 and I know several dozen others in similar situations.
tiahura 4y ago

anotherhue 4y ago

No content with Javascript disabled. Hardly unheard of among a technical audience.

tanishqkanc 4y ago
Ah! That’s unfortunate . All that work of pre-rendering, and it won’t even work with javascript disabled. To be clear, I use a very very tiny bit of javascript only to animate the article elements after render.I guess when that fails, it just doesn’t animate the opacity to 1…hm...
- ChadNauseam 4y ago
  Haha, same thing was pointed out to me when my site was posted to HN. My advice: use a css transition instead of js
  - tanishqkanc 4y ago
    Im not sure if there’s a good way to use css to animate an arbitrary number of children with a delay, while retaining clean markup. I did this before: .article-child { animation-delay: var(—index)*0.025s; } and while rendering, set style tags on each element style=“—index:5”, etc. That works, but it was annoying to maintain, and every single element has these style tags. So I just use Motion One (WAAPI) now.
    - pwg 4y ago
      Drop the animation and just let the browser render the elements and css position/style them. Most 'animations' on otherwise textual articles are merely eye-candy fluff that is totally unnecessary. PS: Viewing with JS on -- yes, totally unnecessary eye-candy fluff in that animation.
      - tanishqkanc 4y ago
        But that’s my vibe!

samsquire 4y ago

Clean code is code you and others can understand and everybody seems to have a different idea of that. Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete. I don't think I would enjoy working on this codebase.

zelphirkalt 4y ago
Naming things is hard. Often when names are very long, they could be shortened, because they are in a function, which already narrows down the context and makes a shorter name still understandable. Very long names can also sometimes be a code smell, if they are relating to a lot of global state, which is not narrowed down in context by where it is defined. Sometimes however, it is really difficult to come up with a shorter name. I think it is definitely a skill, that takes practice and never is really perfected.
lukeramsden 4y ago
The point is to always name your variables / methods / classes as exactly what they do (not how they do it, but what they achieve). If this name looks ridiculous, like `doXAndYAndZAndSideEffect`, then your code is likely poorly factored. I've found it works very well for helping to find good separation of concerns.
thraxil 4y ago
The recommendation I read back in the 90's in Code Complete that has served me well ever since was that variable name length should be roughly proportional to the variable span. "Variable span" being the distance between where the variable is first defined and its last use. Generally that means that a temp variable inside a short function can be a single letter since you can see the full context of its entire lifecycle right there and it's unlikely to be confusing; indeed, a short variable name in that case will often be much easier to read and work with than a longer one. OTOH, a global or exported variable that might be accessed in different files from where it is defined or used across thousands of lines really needs to be descriptive enough that anyone encountering it should know what it's for without having to backtrack to where it was defined. A variable name that's a few words long might be entirely appropriate for that. A corollary is that a large variable span is often an indicator of a bad design. So if you find that you need really long variable names to make your code easy to understand, you might want to step back and see if you could set up some better or different boundaries. I've found this to be a much better rule of thumb than "always use long variable names" or "always use short variable names".

james420 4y ago

the takes in this thread are the worst

motoboi 4y ago

I have never given much attention to functional programming just out of prejudice. Now I read this blog and my head just exploded in the functional part. It's beautiful. What good introductions to functional can you people point me to? Also, good code is like prose. You write to other to read, and you need to guide their minds. Of course you can write in dense, truncated and clever ways, but your audience will be small (even yourself won't like your own prose 6 months from now). Good software is delightful to read.

kabes 4y ago
What part are you referring to? I don't see any FP stuff in that article... It's all imperative code? Anyway I would recommend learning Haskell. I like languages that allow different styles (like js does to a certain extent). But I think it's better to learn a modtly pure OO language like java and a pure FP language like Haskell to be able to make the right decisions in a language that supports both like JS.
- remram 4y ago
  The author refers to it as "declarative programming" when they talk about functional programming. I would link to the section "Functional, declarative programming" but there are no anchors. The table of contents (which the author calls a "minimap") is not clickable either.
antipurist 4y ago
> What good introductions to functional can you people point me to? When people hear "functional programming" many of them will immediately point you to Haskell (and totally forget to mention The Haskell Pyramid [1]). I'd advise you to stay away from it until you _want_ to go deeper down the rabbit hole. Play with Elm and Erlang ("Programming Erlang" [2] and "Erlang Programming" [3] books are great) to un-learn imperative patterns, tinker with OCaml to learn a new way to modularize code. [1] https://patrickmn.com/software/the-haskell-pyramid/ https://patrickmn.com/software/the-haskell-pyramid/ [2] https://www.amazon.com/dp/193778553X https://www.amazon.com/dp/193778553X [3] https://www.amazon.com/dp/0596518188 https://www.amazon.com/dp/0596518188

dataflow 4y ago

Just a note that functional programming here seems to be conflated with declarative programming. They do have some things in common ("no mutable state" being the main one I can recall), and technically I think FP is categorized as a subset of DP, but in reality a declarative program ends up looking quite different from a functional program, so it's with distinguishing the two. To give a trivial example to illustrate the conceptual difference: a declarative program could say something like "the output is the solution to f(x) = 0", defining f explicitly and leaving it to the compiler/interpreter to supply the algorithm for figuring out an x that satisfies it. Note that, as long as x is unique, "try all legal values of x" works, so a viable fallback algorithm always exists; it's just inefficient. Whereas with FP you actually have to supply an explicit function to (hopefully efficiently) compute the output, i.e. you basically have to write f^-1 yourself, which typically results in a very different program - sometimes harder to read, sometimes easier. Now, of course, you could do "FP" by writing f instead of f^-1 and then enumerating all possible inputs as with DP, just as you could write a DP to compute functions explicitly at every step, and you could write imperative programs for all these. But those would be unnatural, and would generally defeat the advantages of the paradigms.

yodsanklai 4y ago

I've noticed many of these articles about what it takes to be a good software engineer talk about code quality. I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. Generally, there's very little bikeshedding on code quality and that kind of things. People are pragmatic and wants to get the work done. It also means there are trade-offs regarding code quality (also dictated by management and pressure to deliver). The challenges are elsewhere. Prioritising, communication, relationships with colleagues, setting up roadmaps and milestones, proposing designs, solving various challenges. Generally, I found software engineering is less and less about writing code. I'm impressed how my colleagues are good at everything. Fluent in most programming paradigms, able to debug complex production issues, do low level performance analysis and so on...

pjmlp 4y ago
Make it work, then make it pretty. Undelivered pretty code doesn't deliver any business value. Same applies to 100% code coverage that isn't running on customers computers.
- karmicthreat 4y ago
  There are a ton of people at all levels that don't get this.
  - cainxinth 4y ago
    I think it was Judd Apatow who said “You have to give yourself permission for the first draft to be shit.” The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.
    - dinosaurdynasty 4y ago

tanishqkanc 4y ago

Hi! I’m the creator of the post. Thank you for all the comments on my post! I’m glad more people are getting to see it. Thanks for posting, @antidnan! Reading through, it looks like I have some rough edges of my website to clean up as well...

scary-size 4y ago
I enjoyed reading your blog post. It was very well written. Most of your points resonate with me.
- tanishqkanc 4y ago
  Thanks!
sergiosgc 4y ago
Congratulations on the post. One may agree or disagree with the content, but the text is clear, to the point, and generally very well written. Good writing is, to me, the foundation of a good engineer. I know excellent engineers who are not great verbal communicators, but every excellent engineer I know writes like you do. I think it is the result of a structured thought process, that flows naturally into a structured clear text.
- tanishqkanc 4y ago
  Thank you so much! I’m so glad it gave off that impression. I went through a lot of revision and planning to write it: I had learned a lot, and wanted to organize all of it carefully. I’m glad it paid off!
antidnan 4y ago
Hope you didn't mind me posting it! I was reading through the parser you posted yesterday and stumbled onto your blog :)
- tanishqkanc 4y ago

yotamoron 4y ago

6 years of experience does not make one a senior engineer. I`ll be polite and say that most engineers with 6 years of experience I know are not seniors.

yotamoron 4y ago
So, just to make myself clear - there are very talented engineers with just a few years of experience, however that's the extreme exception. As pointed here, it is rare to work on interesting and trail blazing stuff - that's why it takes time, sometimes years, to gain the experience. There's a low probability of actually working on something meaningful, therefore you have to fight it with repeated attempts of finding the interesting stuff - and that takes time. Obviously, time is not the only thing needed to become a really experienced engineer, but - in almost all cases - its a prerequisite.
jrockway 4y ago
I think there's a split in the industry; outside of FAANG senior means "certain amount of time spent in front of the computer getting paid", inside FAANG, it's a set of behaviors encapsulated in a particular mid-career job title.
- grayclhn 4y ago
  Inside FAANG, it is literally a job title.
  - dionidium 4y ago
    "Senior engineer" is a job title at every place I've ever worked.
  - jrockway 4y ago
    Yes, very good point. I added a little edit to clarify that.
- twic 4y ago
  Outside of FAANG, senior means "we can't pay as much as FAANG but we will call you senior when you have two years of experience and no idea what you're doing".

dchapp 4y ago

> Long verbose names don't cost anything They absolutely do have a cost. The question is whether the benefit they bring in implicit documentation is worth their cost. > Even beyond the DX of readable names, it also acts like a type-checker. By reading the code, you can verify at least the semantics make sense. I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name.

__Parfait__ 4y ago
What's the cost?
- dchapp 4y ago
  Readability. In particular, an increase in the rate at which long, verbose names which are mostly the same are confused with one another.
shepherdjerred 4y ago
> I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name. Have you never worked in a dynamically typed language?
- dchapp 4y ago
  I have. I prefer statically typed languages.
- plonk 4y ago
  Python is only palatable with strict type checking everywhere. I don't see how unchecked dynamic typing can bring anything else than chaos in a large project.
nnnnico 4y ago

Nimitz14 4y ago

I think the lessons learned are exactly those you should be as a junior, nice post.

confidantlake 4y ago

The passionate arguments about what a senior is or isn't seems strange to me. Who cares if someone is junior, senior, jedi, ninja whatever. Using senior to distinguish between someone who just started and someone who has been there for a while seems perfectly fine.

plaguepilled 4y ago
Agreed. Title worship isn't helpful. Perhaps a qualifier would have avoided this whole issue, eg "my more senior teammate" or "my mentor". Then again, this seems like a reader issue, not an author issue. The salient point was never that Chet had status X and therefore could teach skills Y, it just was that Chet taught skills Y.

Retr0id 4y ago

I would be very interested to read an article titled "What I learned as a senior engineer working with a new grad".

smm11 4y ago

Been in the field more-or-less since the late 80s. There are days, weeks really, when I can't tell you what I've done. The business just chugs along. If I'm gone a day, though, my phone will ring by 10 a.m.

AnimalMuppet 4y ago
Bjarne Stroustrup said "It is essentially impossible to judge a programmer on the basis of only one year's work."

pca006132 4y ago

I don't think 'type unsafe' is the only way to enable decoupling. For adding new commands, it can be done in a pretty type safe way. The problem is that the `ICommandHandler` may be used in a lot of places expecting different parameters, so they try to simplify the interface by using `any` as the parameter type. > Static typing is really a form of testing No! Static typing is not a form of testing. Static typing or static analysis, is an approximation of you program behavior, because it is undecidable in general. Depending on the properties of the type system, you can guarantee that you program doesn't go wrong if it is well-typed, where the definition of 'go wrong' depends on the type system. On the contrary, testing can check the behavior of your program with respect to a set of inputs, and it doesn't guarantee anything outside that set of input. You are doing state partitioning by doing a static analysis over your code to determine what tests you may need, and test some of them.

adregan 4y ago

If I may pick on one piece of advice here: intermediate variables. I think both the bad and good examples are both equally unreadable and feel the "good" version would introduce more confusion into a code base than the "bad" example. For example, if I came across the example in code, I would begin to wonder why the `deltaX` variable exists at all if its only purpose is to be renamed `translateX` and spend some time tracing the code to see where the variable falls out of scope and to see if it's important. Then I might wonder whether it used for something else at some other point in time and trace the history of these lines (somewhat akin to nerd sniping). Now I'm focusing on the variable as if it's important when really the important bit is the relationship of the current to the initial. The code is obscuring the fact that "delta" is `current - initial`. Look how many times the pattern is repeated! Perhaps we need an abstraction that can produce the delta for us. However, the data structure makes that a little bit tricky as scrollTop is held in an ad hoc manner, so maybe we should update the data structure so that we can eventually have an api like: type ScreenPoint = { x: number; y: number; scrollTop: number } type toDelta = (current: ScreenPoint, initial: ScreenPoint) => ScreenPoint // example implementation of toDelta using ramda for brevity const toDelta = R.mergeWith<ScreenPoint, ScreenPoint>(R.subtract) const delta = toDelta(current, initial) shadow.style.transform = `translate(${delta.x}px, ${delta.y + delta.scrollTop}px)` Intermediate variables can be tricky because you can't always trust that the name matches what's actually going on inside, so you have to read everything anyhow.

svnpenn 4y ago
> using ramda for brevity please don't do that. Unless the article also uses Ramda (it doesn't) its not really appropriate for you to do so. If you want to use Ramda in your own, personal code, go ahead. But if you're posting a public example for other people to look at, including Ramda only makes sense if you're on a Ramda forum. The whole point of this article is clarity in programming, you've reduced that with you decision to include some obscure package.
- adregan 4y ago
  It was only intended to be illustrative of thinking about the operation as merging two identical data structures in a manner that produces the result. You could accomplish the it using any technique your codebase prefers be it FP, OOP, &c. (some languages might even handle such an operation natively). In this case, I felt that it was sufficiently close to pseudo code “merge these objects by subtracting identical keys left to right,” but I understand your objection to obscurity. I actually feel that the implementation in this example is fairly unimportant.

pramodbiligiri 4y ago

Two of the points in the article are at cross purposes. The author mentions doing Mindful Practice but later says to be Problem Oriented. The first one implies a background thread making judgments that is constantly running in the back of your mind. The second needs you to ignore everything but the problem at hand. I’d go with the latter, esp if you’re new to the job. Let judgments accrue over time rather than go looking for them in the middle of a task at hand.

pojzon 4y ago

I find it hilarious the fresh grad with 6 months experience that doesnt know how to use git properly calls himself a “fullstack developer”. JS dev is a state of mind it seems.

mriet 4y ago

Sorry, but how the @#€& is 6 years a senior engineer? I consider all of the lessons that he mentions to be things that junior engineers learn before becoming medior engineers.

black_13 4y ago