20 ms·

Absolute truths I unlearned as junior developer (2019)

461 points by ddtaylor 4y ago

shade23 4y ago
Previous Discussion from 2019: https://news.ycombinator.com/item?id=20124018 https://news.ycombinator.com/item?id=20124018
deleted 4y ago
[deleted]
V-2 4y ago
> Loads of companies and startups have little or no tests. Personally I haven't seen a codebase with no tests since like 12 projects ago, give or take. But your mileage may vary of course. Maybe I've been just lucky.
argovaerts 4y ago
Luckily she didn't do COBOL or PL/I, or she would be fixing stuff 24/7. For me it was more copying others and don't try to come up with a better/more clever solution for something every single time. Sometimes the current solution is just good enough.
begueradj 4y ago
No truth is absolute, to begin with.
- MaxBarraclough 4y ago
  Does that apply to itself?
ChrisMarshallNY 4y ago
> That’s why mentors are so important, and the team you work with is worth so much more than a couple bucks in your paycheck. Don’t accept a junior position where you’ll be working alone, if you can help it! And don’t accept your first role (or, honestly, any role) based on salary alone. The team is where the real value is. Couldn't agree more. Of course, with today's attitudes towards us olds, and the average term of employment as an SWE being about a year and a half, I'm not so sure how big a role mentorship plays. I think that having folks be responsible for their code, from napkin sketch, to deprecation, is a great way to teach us how to do good code. That's been the case for me, for almost my entire career. A quick shufti through my code repos will show the results.
- brunooliv 4y ago
  It's still baffling to me how short avg tenure for SWE is, in general. I feel that after a year, maybe, is when I finally start getting the lay of the land, meet some people, start understanding more of the domain and can start causing impact worthy of my paycheck. I'm now at 3.3 years at my current gig and I'm feeling like I have superpowers, if that makes sense. I think it takes time to be in a position to really do a good job and see some earlier decisions paying off (or not) and it's speeding up my learning and responsibilities a lot!!
  - ChrisMarshallNY 4y ago
    Not that baffling. Paychecks expand by orders of magnitude, when changing companies, and corporations treat their loyal employees like dirt. It’s a systemic issue that needs to be dealt with in the C-Suite (which means there’s no relief in sight).
  - sbarre 4y ago
    In my 20+ years as a developer, I've always advised developers working under me to move around and not stay in the same place too long. After 3 years it's potentially time to start looking around.. It's not just about the money, you also want to acquire varied experience and see how different teams work and tackle different problems, and expand your own experiences. You can even come back to a previous company some years later and probably come in at a higher spot than you'd have been able to get if you stayed put and tried to climb internally! I've seen this many times. We called it the "zig-zag".. You do make a good point about sticking around long enough to see the outcome of decisions and the successful(?) launch of products or projects.. That is important for sure, and it should impact the timing of making a move to a new thing. That said, things are a bit extreme right now in terms of how quickly people change jobs, but as someone else said the way salaries have exploded, you can move to the literal same job somewhere else and get a 30% raise, so it makes total sense why people are doing it. That may not last forever, so get your raise while you can! New opportunities will always be there.
    - ChrisMarshallNY 4y ago
robertlagrant 4y ago
I think the point about senior job titles is good. I haven't inspected other industries, but I doubt that many places think sub-five years (or even maybe sub-ten) is a senior level of experience. Admittedly, as the article points out, ours is a particularly diverse field, but if you're going to have a label for "person who's done this for quite a while" you'd imagine the time period would be longer.
beepbooptheory 4y ago
Can people even be "junior" anymore? Its relatively hard to find those kinds of positions anymore, or at the very least they are somewhat sparse. Thought it was interesting that this month, much more of the "Wants to be hired" postings were juniors compared to what people were looking for in the "who's hiring" postings. Ive ctrl-fed the monthly job postings for 'junior' for the better part of year, and its getting less and less. Why hire a junior when surely you can find some established OSS person? Its so competitive these days, as much as I want personally for this not to be the case (so I can score a job), I dont see why any company would want to hire a junior dev anymore. Interviews I get tend to play this out. Everyone likes, abstractly, the pedagogical ideal of bringing someone in to learn, but when its their money on the line, they go for the most experienced individual they can acquire.
- sbarre 4y ago
  Our company has a structured junior onboarding program. We take in a cohort once a year and they go through a 12-month program that happens while they are on the job in their various teams, designed to help them continue to grow their overall developer skills and also learn how things work at our company (we're a pretty big enterprise). This was sort of inspired by Facebook's internal bootcamp idea, but it also grew out of the realization that we were not set up to take in juniors without some kind of structure that ensured they were provided guaranteed support to keep growing into their roles, since the teams across our department (of ~500 people) have such different focus. This program exposes all of them to the different facets of being a front-end and back-end developer, no matter what team they are on. The juniors have 2 to 4 sessions per week on different tech topics, with courses taught by volunteers from within the department who sign up to prepare the course and present it. The program has a been a huge success (both for the juniors and for the more experienced folks giving the courses), and we are starting our 3rd cohort this month. When we opened the job posting to take applications this year, we got 450 applications in 3 days, for 10 possible positions. I wish we could expand the program to take in more people but we've found that 10 is what we can handle for now.
  - beepbooptheory 4y ago
29athrowaway 4y ago
> Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own (or with minimal feedback) for 5 years. I learned 10x more coding C++ and Rust in my room, watching Twitch streams of people doing interesting things and watching Cppcon talks than many years of coding in other languages at work. > Disorganized or messy code isn’t the same as technical debt. Try fixing a production problem at 4 AM and having to read some messy code. It will make you think "why did something think it is acceptable to have this in a mission critical system?". Try having to maintain a critical feature in a non-breaking manner and having to deal with some messy code. It is frustrating. So, messy code is unprofessional. It's bad workmanship.
- sbarre 4y ago
  >> Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own (or with minimal feedback) for 5 years. > I learned 10x more coding C++ and Rust in my room, watching Twitch streams of people doing interesting things and watching Cppcon talks Exactly! You had a whole team supporting you, asynchronously.
- hazz99 4y ago
  Off-topic, but what streams! Would love to follow along with some interesting Rust ones.
  - 29athrowaway 4y ago
    Mostly streams about competitive programming, security, OS development, programming language development and game development. Streamers in these categories come and go. On Twitch you can find the developers of the zig and jai programming languages, the developers of Factorio, top competitors from codeforces, and all sort of interesting projects. Ocassionally there are university professors, security researchers, etc.
mikewarot 4y ago
I've never had my code reviewed. The majority of my code was written in the days of MS-DOS, Turbo Pascal, and eventually Windows and Delphi. I was the solo developer at a small firm in the Chicago area with one product, which I had written. As a retired person, I think it's like skydiving, something I'll never do. Unless of course, something on my github takes off.
sidlls 4y ago
The point about over documenting is okay, but reliance on automation and tests is completely separate from documentation. They serve different purposes. The code is not (all of) the documentation. People who rely on code comments, API docstrings/comments, and tests as documentation are thinking of documentation only at the level of the interface, not the bigger picture: that's a junior mentality. Also, documentation becomes stale and unreliable because too often too little attention is paid to it. It's not as fun as writing code, and it's arguably harder since the audience is either non-technical or has a different area of technical expertise.
KaiserPro 4y ago
> 5. Everything must be documented!!!! I mean it should > Focus on automation over documentation where appropriate. Tests or other forms of automation are less likely to go out of sync. So instead I try to focus on writing good tests with clear language, so developers working on code I wrote are able to see how the project functions with working code. This makes me uneasy. I don't want to pick on OP, because its a common enough opinion. However both is best. I don't think people really read tests to understand code, normally because tests are so contrived and shit they they are a burden to be ignored.
- corrral 4y ago
  > However both is best. I don't think people really read tests to understand code, normally because tests are so contrived and shit they they are a burden to be ignored. I have read tests for this kind of reason, but usually in codebases without static types. I consider static types mostly a form of machine-verifiable and tool-friendly documentation.
superb-owl 4y ago
The meta-lesson here is that considering certain truths to be "absolute" is harmful. The greatest asset you can have as a programmer is flexibility. Understand the tradeoffs (e.g. tech debt vs over-engineering, thorough testing vs shipping quickly) and navigate them intelligently, rather than dogmatically pushing everything to one side of the tradeoff.
Jemm 4y ago
Senior developer at 21 is part of the problem with software now. Companies only want to hire young people but those hires have very little life skill or knowledge outside of their field. They arrive with vim for the latest and greatest shunning the tried and true. Yes architectures need to evolve, of course, but it isn't evolution. It is flavour of the generation with new trumping functionality and usability in many cases. The author does mention the importance of a mentor and I completely agree with that. I think mentor should be a job title with extra perks, rather than someone who is 4 years older than you who knows where the best espresso machine is. Grump.
newfie_bullet 4y ago
Really enjoyable read. I'm in a software mentoring role now and definitely going to share this with new devs - always important to recognize just how much you don't know and being too rigid in your thinking can really hinder things.
stakkur 4y ago
>So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. In my experience, this is the norm, not the exception. Especially in certain areas like 'web development'. Everybody talks about tests and nods sagely in their direction--but I've rarely encountered some kind of meaningful test harness.
jnash 4y ago
Wow. What a refreshingly smart developer. Somebody who is smart enough to question their own believes and learn from it. It is so rare to meet somebody like that. Kudos!
phibz 4y ago
I see people get tech debt wrong. I've heard it called sorts of things. My current team thinks it's easy tasks, 1 pointers. I've seen it called sysadmin work that isn't business focused. In my opinion tech debt is the result of a choice. Tech debt is the remainder of a solution modulo good enough. You choose to do something you consider less than perfect with the understanding that you're just delaying some of the work until later. That left over work is Tech debt. For example, we need to implement auth on our web app, but let's hard code the permissions and do RBAC later. That's hard and not really valuable with such a limited feature set. RBAC in your web app is therefore Tech debt.
mattkenefick 4y ago
This is like.. a list of things to avoid doing.
waltermartinez 4y ago
Wass good good with it .
devnull3 4y ago
Small piece of wisdom I received when I was an intern: "Never get sentimental with your code"
- LandR 4y ago
  I get paid to write code, I couldn't care less if it's deployed or not. If they pay me to write it, and it doesn't get used, that's their waste of money / time, not mine.
- Nimitz14 4y ago
  Applies to many things, Stephen King on writing: "You have to be willing to kill your darlings."
- seer 4y ago
  While this is indeed a very good advice, I learned how to cope with this a little better than “just don’t care”. Mostly because I do enjoy coding, and am still sentimental with code I’ve written decades ago. The trick is to split that kind of code into their own libraries. Preferably open sourced. This way once your code has outlived its usefulness to your current project it can still live on, and be useful somewhere else. For example one of the first things I’ve written as a jquery plugin that I really liked, I polished it, wrote some docs and demos, and in its day it was pretty cool (stayed on HN homepage for two days). I still got mentioned for it years later by people actually using it even now. Even if I myself don’t find it useful at all, it’s still nice to see it is used by someone somewhere.
- mypastself 4y ago
  I’ve had customers request complete rebuilds of functionalities several times over, destroying weeks of effort each time… and I’ve never cared, as long I’ve clearly communicated my concerns beforehand. I’m precious about the code only while developing it. The process is the fulfilling part to me, not how the end result is used. The approach has its drawbacks, I’m sure, but I find it very easy to not grieve over paid-for-but-unused work.
- augustk 4y ago
  As long as the code is versioned you don't completely kill your checked in darlings.
DougMellon 4y ago
> Good enough is good enough. I’ve only been in my first role for about two months and this one hit the hardest for me personally. I imagine it has a direct correlation with impostor syndrome, but I spend a lot of time writing things over and over again because in the back of my mind I’m thinking “is this the correct approach? Will they think I’m failing if it’s not how they’d do it?” I consider myself lucky that I’m in a position with a great team that’s very helpful but I struggle to balance the line of when to ask questions - which often stems from not trusting myself to be to their standard.
- dgb23 4y ago
  That’s actually great. You are playing and exploring, which will definitely lead to deeper skills. It’s not impostor syndrome, it’s just realizing where you are and putting in the time to improve. It’s only an issue if you stress out too much over it, or if you spend too much time doing it. Maybe schedule a time for this type of work, like 1h a day, or 3h. Really depends on the type of work you’re doing and what the circumstances are.
- phil-martin 4y ago
  It's a hard one to learn in the first 5 or 10 years or so I think. For me the correct approach is the one that solves the problem, feels good enough for the user (with varying definitions of good enough depending on the business goals), and doesn't create a maintenance headache. There is a large amount of room in there for correct solutions.
- ZephyrBlu 4y ago
  I also had the problem of not wanting to ask questions and look stupid, and my manager told me to ask the questions I need to get the task done. Very simple and effective. Also, instead of re-writing things in solitary many times over it would be a lot more effective to write something pretty good (In your eyes) and then ask for feedback on it. That way you can either validate that you're doing a good job, or start to learn what "good" looks like.
  - sigstoat 4y ago
camjohnson26 4y ago
The truth I had to unlearn is that coding is a solitary activity, and that coding is the most important part of a senior software engineer’s job. Now I rarely have the chance to code for a few hours straight because if I have enough information to write code then all that’s left is the easy part. The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. Not to mention onboarding newer devs who haven’t learned the technologies yet.
- AtNightWeCode 4y ago
  Where I live the worst of this is that one is often expected to be the head of a team as well as lead developer. Sitting in meetings with people talking about personal matters was not the reason I became a developer. The purpose of having autonomous teams with agile development is to speed up development by defining responsibility between different roles in the team and to give the team a sense of ownership that will enable quick decisions and shorter time to production. Scrum for instance also emphasis the need for protecting the developers from the outside. But in this agile post apocalypse it seems like the result have become the opposite.
  - chrisweekly 4y ago
    Yeah, I keep seeing this enterprisey top-down centralized micromanaging cargo-cult "digital transformation" so-called "Agile" rigid overspecified prescriptive process conveniently ignore the crucial SELF-ORGANIZING TEAMS aspect of the original manifesto.
- taylodl 4y ago
  Yep. Coding is a team sport. When hiring, think more along the lines like you're drafting for an NFL team. How does the potential hire's talents complement the team's? Will the personalities and the way they work fit with the team's? You ignore team culture at your own peril and that's been true now for decades.
- temac 4y ago
  It depends on tons of factors. Yes there are things besides designing and coding, and they can be harder depending on people and projects, but some strong links to the technical parts are always needed, in the sense that a manager is not an evolution of an engineer. Cutler wrote non negligible parts of NT. Linus doesn't "code" much anymore but still has an enormous technical impact. Limiting the dichotomy to "coding" vs anything else is really weird because coding is just a part of design, and never should have been considered the absolutely only essential part of software engineering -- and that's the case regardless of your seniority. Otherwise you can as well be considered a kind of secretary with additional specialized skills. Even if you don't recognize the other activities you are still doing them, at least temporarily in your head even when working on a project alone. And also there are tons of areas where code/design can still be tricky even for highly talented people. E.g. writing a state of the art compiler is not necessarily easy even when the problem has been well defined.
oconnor663 4y ago
> Things like indendetation, formatting, naming – god forbid you did it differently than I would have. I agree with chilling out about this when it's a human making the changes...except now that we have autoformatters we can actually be more pedantic about this than ever before :) If the autoformatter doesn't agree with what you wrote, bam, red CI. > Everyone writes tests A big thing I've learned over the years is that making your code testable often takes more foresight and experience than actually writing the tests. "What's the right way to test this?" becomes an important question when starting something new. And "Can we make it easier to test this?" becomes an important question when inheriting something.
- latch 4y ago
  This is why a lot of people don't test or claim that testing takes more time since "we spend half our time fixing the tests" - a lack the experience to design code that's testable. I think it's also worth pointing out that up to a point, code that's testable tends to be more maintainable. This largely has to do with coupling and cohesion. Code that's hard to test in indicative of too much coupling and/or not enough cohesion. This pendulum can swing too far the other way though. I hate when relatively straightforward code is made more complicated in the name of testing (often comes up when dealing with non deterministic sources of data, such as the current time). But this, in my opinion, is a comparatively small problem. 100% you should test private functions if it makes sense. Whether something is public or not has no bearing on the value you'll derive from testing. If anything, sometimes you can avoid real headache by focusing specifically on the private function (by definition, the private function has to be more focused than the public function calling it). Also, we should probably all be fuzzing more.
  - deleted 4y ago
    [deleted]
  - tziki 4y ago
    >I think it's also worth pointing out that up to a point, code that's testable tends to be more maintainable. This largely has to do with coupling and cohesion. Code that's hard to test in indicative of too much coupling and/or not enough cohesion. I feel like whenever someone complains that the code is hard to test, there's always someone who's quick to claim that it's just indicative of problems with the code itself, rather than an issue with writing tests. This rings false to me. Making code testable is simply one aspect that you need to take into consideration when writing code, along with readability, extensibility, modifiability etc. If you remove one of those constraints, it often becomes easier to focus on optimizing for the other constraints. I don't believe that adding testability as a constraint somehow makes the code better - more often, it just forces you to write the code in a certain way which feels 'logical' when considering the constraint of testability, but makes it harder to optimize the other constraints. The feeling of 'revelation' when you end up needing to modify code to make it more testable is mostly just the constraints imposed onto the code.
jehlakj 4y ago
For me, it was that I thought that being a good programmer was that I write clean code with enough abstraction and indirection to make it future proof. Boy I was wrong. Unless you’re doing the same thing you’ve done for years, you can’t tell the future. And just when your unnecessary abstraction is wrong, this the reason why we’re talking about tech debt in the first place. Because nobody wants to touch it. Unfortunately, I didn’t have anyone to tell me this for the longest time. It wasn’t until I had to fix a bug for something I wrote in the past, and I couldn’t figure out just what I wrote. Now I try to write dumb and simple (yet sensible) code until there’s a good reason for abstractions. I have nothing to prove at this point in my career.
- snarf21 4y ago
  Well said. We are having a similar "fight" where I work now. Way too much premature optimization. I think the one concept that takes a while to really understand is to focus on separation of concerns. It is far too easy to get encapsulation wrong. People (imo) generally forget to apply the SoC test that tells them where to draw the line. We also have a lot of parallel development where re-factoring a View (Screen) could cause a rippling failure to other people's code. Too often they try to reuse everything instead of the important part of extracting the shared business logic into a XXManager and letting the Views just be dumb. Who cares if two Views developed in parallel might be too similar? It might change in the future and don't have to worry about 1 View doing 2 jobs.
- li2uR3ce 4y ago
  > Now I try to write dumb and simple (yet sensible) code until there’s a good reason for abstractions. Good abstraction is a lot harder than most think. We tote abstraction's benefits as a reason for abstraction but fail to recognize bad abstraction and how it completely negates any would be benefit. Too often abstraction (so called) requires a lot of research into how it's implemented. By the time you figure out enough implementation details to use the abstraction, you could have implemented it yourself quicker. It saves no time or effort but you're stuck with it because existing code is hard to part with. If you're not reliving your users of a shit ton of implementation details then it's just not good abstraction. Code for someone who doesn't want or have time to learn the details. Often this will be your future self despite your current believe that your mind is a steal trap and would never forget how you did this stuff.
pvg 4y ago
Discussion at the time, 516 comments: https://news.ycombinator.com/item?id=20124018 https://news.ycombinator.com/item?id=20124018
monksy 4y ago
Bad developers and companies have little to no testing. Yes, it's fairly common out there. Doesn't make it right.
tornato7 4y ago
I still reminisce about the first big project I ever built. As an intern I was told high level what to do and given two years alone in a room working eight hours a day to figure out how to build it, zero guidance from anyone. I didn’t really have any concept of importing libraries or using open source software, so literally every part of this huge and complex application was custom-written by me. All UI elements were custom designed from shape primitives, including a full time series graphing utility and a drag-and-drop programming language with compiler. The database was built by me using a custom binary data format I had invented and lots of disk IO. It was extremely fragile, but it was also the most beautiful and functional app I have ever used to date. I wish it weren’t a Java applet so I could host it on the web again, but alas.
- confidantlake 4y ago
  This is awesome. I often think I would be a better developer if I had something like this when I was first starting out. Alas, 95% of my experience is gluing libraries together to check off Jira tickets.
- puchatek 4y ago
  What year was this?
- smt88 4y ago
  > it was also the most beautiful and functional app I have ever used to date I laughed at this because of course a software developer would think the best-ever UX is the one they built in complete isolation with exactly 1 user (who happpened to also be the developer and designer).
  - baobabKoodaa 4y ago
    I see your point, but I would give GP the benefit of doubt. Their app might be more beautiful and more functional than you think!
- bilekas 4y ago
  This seems to be the extreme opposite though of other posts with badly structured responsibilities. As a senior I will always rely on having a set of eyes or other opinions and viewpoints. Its invaluable! I wonder if you went back to the source code now would you feel the same about its brilliance! :)
LAC-Tech 4y ago
I deployed by ssh-ing into a server and running git pull. That sounds wonderful. Let's do that again.
- gjulianm 4y ago
  There's a reason most deployments moved away from that: - Sometimes you need more complex actions to update a service than just "update the code". Migration scripts, dependent services restarts... - It's fine on one server, but the more you have the more difficult it gets - Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. - Too easy to say "let me just modify this thing here in production" and end up with bug fixes that are only applied on certain machines and certain versions... I get the "let's do things in a simple way again" sentiment, but it's not like the complexity is there because people like complexity.
  - feoren 4y ago
    > Too easy to say "let me just modify this thing here in production" This sounds crazy to me, like saying "it's too easy to say 'let me just poop on the floor right here' instead of going to the bathroom properly". What!? I can sorta vaguely understand why someone might think that's a little easier in the moment, but someone who has that little control of themselves needs serious help, if not a good old-fashioned kick out the door. That is not a technology problem, it's a human problem -- and a major one.
    - gjulianm 4y ago
      The reality is that those things happen. Technology must inevitably deal with human problems too, it isn’t as easy as saying “just don’t do that thing”.
      - LAC-Tech 4y ago
  - 4y ago
chasil 4y ago
I'll just repost these thoughts by Dave Cutler, designer of the kernels for Windows NT/XP(...) and (Open)VMS: “I have a couple of sayings that are pertinent. The first is: ‘Successful people do what unsuccessful people won’t.’ The second is: ‘If you don’t put them [bugs] in, you don’t have to take them out.’ I am a person that wants to do the work. I don’t want to just think about it and let someone else do it. When presented with a programming problem, I formulate an appropriate solution and then proceed to write the code. While writing the code, I continually mentally execute the code in my head in an attempt to flush out any bugs. I am a great believer in incremental implementation, where a piece of the solution is done, verified to work properly, and then move on to the next piece. In my case, this leads to faster implementation with fewer bugs. Quality is my No. 1 constraint – always. I don’t want to produce any code that has bugs – none. “So my advice is be a thinker doer,” Cutler concluded. “Focus on the problem to solve and give it your undivided attention and effort. Produce high-quality work that is secure.” https://news.microsoft.com/features/the-engineers-engineer-computer-industry-luminaries-salute-dave-cutlers-five-decade-long-quest-for-quality/ https://news.microsoft.com/features/the-engineers-engineer-c...
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]
DeathArrow 4y ago
>In reflecting on this first decade of getting regularly paid money to type weird symbols into my Terminal, I wanted to take some time to share some of the ways my thinking shifted over the years as a developer. I think that's a very low take of what means being a developer. I am not getting payed for that, I'm getting payed for solving problems. Some easy, some hard, some very hard.
DeathArrow 4y ago
>I learned all that fancy Angular-specific JSDoc syntax. My code was always twice as long because it had so much documentation and so many comments That's a very bad habit. Code should be self documenting. If you need to write comments to explain what the code does, you've done a poor job at writing it.
- Spixel_ 4y ago
  Comments aren't bad per se, but they should explain Why vs. How.
fzeroracer 4y ago
For me, one of the things I learned early on is that there are a lot of salesmen in the software world that want to sell you something. Whether its tooling, methodology, classes or whatever. Cargo culting is rampant and everyone wants to sell you their version of a hammer to nail down any problems with your software. This doesn't make them necessarily wrong or not have valuable things to bring to the table but much like everything else you should be careful not to fall into the trap of assuming that it works for them, therefore it works for you.
dzikimarian 4y ago
What I learned is that, there is no absolute truths in this line of work. There are only tools and techniques, which can be applied depending on the context. Some of them fit 99% of times. Some almost never. None is written in stone and any of them won't make project good or bad on its own, let alone commercially successful. You become senior, when thrown into a new environment, you can can say which of these will help to move forward, and you know that not because "everyone does that", but you truly understand what they will do to the project and the team.
- dgb23 4y ago
  That’s the essence of the post. Every “absolute truth” is more of a talking point that is relativized and leads to more insightful and grounded comments and learnings.
brunooliv 4y ago
One more thing not in the article is that sometimes, leadership or whoever is responsible for the roadmap, can FAIL to do their due diligence and you can end up a few months working on something meant to be "a great product" just to realize after it ships, that the customer just isn't buying it.
tobyhinloopen 4y ago
Cmon guys just write some damn tests. It’s not that hard
- dgb23 4y ago
  The keyword is “some”. In web dev there are things that lend themselves to automated testing, for example domain logic. There, it is often most beneficial and most helpful during development. Start with that, it won’t save time if you don’t. Other things, like UI, I think are best tested manually and visually. This takes a ton of time but leads to the highest quality and confidence.
- pojzon 4y ago
  Its very easy to force ppl to write tests. For example Sonar QualityGate on new code added to the code base. Its hard to make ppl write tests that make sense and are worth running.
jollybean 4y ago
This is well written. There list should be longer.
wronglyprepaid 4y ago
Many good points and a great article overall, though one that i think is possibly most overlooked is: > Having some technical debt is healthy
unnouinceput 4y ago
Quote 1: "Next year, I’ll be entering my 10th year of being formally employed to write code. Ten years! And besides actual employment, for nearly 2/3 of my life, I’ve been building things on the web. " Math: If 2/3 => 10, then 3/3 => X. X = 3/3 * 10 div 2/3; X = 30/2; X = 15. So the author is 15 years old and writing code since 5 years old, and during this time he was also employed. Unusual but not unheard to be employed as a child. Quote 2: "I was 19 years old when I applied for my first technical job. The position I was applying for was called “Student Webmaster”." Oaw there, we just calculated she's 15 so how was she 19 when first employed? Something's off on one of above quotes.
- mypastself 4y ago
  Besides employment. So like the rest of us, she likely coded before she started doing it professionally. I don’t think your “2/3 => 10” equation is supported by the quote. Seems pretty clear she started building things at 9 or 10, and got her first job a decade later.
Lapsa 4y ago
I deliberately skip the semicolons

461 points by ddtaylor 4y ago

Previous Discussion from 2019: https://news.ycombinator.com/item?id=20124018 https://news.ycombinator.com/item?id=20124018

deleted 4y ago

[deleted]

V-2 4y ago

> Loads of companies and startups have little or no tests. Personally I haven't seen a codebase with no tests since like 12 projects ago, give or take. But your mileage may vary of course. Maybe I've been just lucky.

argovaerts 4y ago

Luckily she didn't do COBOL or PL/I, or she would be fixing stuff 24/7. For me it was more copying others and don't try to come up with a better/more clever solution for something every single time. Sometimes the current solution is just good enough.

begueradj 4y ago

No truth is absolute, to begin with.

MaxBarraclough 4y ago
Does that apply to itself?

ChrisMarshallNY 4y ago

> That’s why mentors are so important, and the team you work with is worth so much more than a couple bucks in your paycheck. Don’t accept a junior position where you’ll be working alone, if you can help it! And don’t accept your first role (or, honestly, any role) based on salary alone. The team is where the real value is. Couldn't agree more. Of course, with today's attitudes towards us olds, and the average term of employment as an SWE being about a year and a half, I'm not so sure how big a role mentorship plays. I think that having folks be responsible for their code, from napkin sketch, to deprecation, is a great way to teach us how to do good code. That's been the case for me, for almost my entire career. A quick shufti through my code repos will show the results.

brunooliv 4y ago
It's still baffling to me how short avg tenure for SWE is, in general. I feel that after a year, maybe, is when I finally start getting the lay of the land, meet some people, start understanding more of the domain and can start causing impact worthy of my paycheck. I'm now at 3.3 years at my current gig and I'm feeling like I have superpowers, if that makes sense. I think it takes time to be in a position to really do a good job and see some earlier decisions paying off (or not) and it's speeding up my learning and responsibilities a lot!!
- ChrisMarshallNY 4y ago
  Not that baffling. Paychecks expand by orders of magnitude, when changing companies, and corporations treat their loyal employees like dirt. It’s a systemic issue that needs to be dealt with in the C-Suite (which means there’s no relief in sight).
- sbarre 4y ago
  In my 20+ years as a developer, I've always advised developers working under me to move around and not stay in the same place too long. After 3 years it's potentially time to start looking around.. It's not just about the money, you also want to acquire varied experience and see how different teams work and tackle different problems, and expand your own experiences. You can even come back to a previous company some years later and probably come in at a higher spot than you'd have been able to get if you stayed put and tried to climb internally! I've seen this many times. We called it the "zig-zag".. You do make a good point about sticking around long enough to see the outcome of decisions and the successful(?) launch of products or projects.. That is important for sure, and it should impact the timing of making a move to a new thing. That said, things are a bit extreme right now in terms of how quickly people change jobs, but as someone else said the way salaries have exploded, you can move to the literal same job somewhere else and get a 30% raise, so it makes total sense why people are doing it. That may not last forever, so get your raise while you can! New opportunities will always be there.
  - ChrisMarshallNY 4y ago

robertlagrant 4y ago

I think the point about senior job titles is good. I haven't inspected other industries, but I doubt that many places think sub-five years (or even maybe sub-ten) is a senior level of experience. Admittedly, as the article points out, ours is a particularly diverse field, but if you're going to have a label for "person who's done this for quite a while" you'd imagine the time period would be longer.

beepbooptheory 4y ago

Can people even be "junior" anymore? Its relatively hard to find those kinds of positions anymore, or at the very least they are somewhat sparse. Thought it was interesting that this month, much more of the "Wants to be hired" postings were juniors compared to what people were looking for in the "who's hiring" postings. Ive ctrl-fed the monthly job postings for 'junior' for the better part of year, and its getting less and less. Why hire a junior when surely you can find some established OSS person? Its so competitive these days, as much as I want personally for this not to be the case (so I can score a job), I dont see why any company would want to hire a junior dev anymore. Interviews I get tend to play this out. Everyone likes, abstractly, the pedagogical ideal of bringing someone in to learn, but when its their money on the line, they go for the most experienced individual they can acquire.

sbarre 4y ago
Our company has a structured junior onboarding program. We take in a cohort once a year and they go through a 12-month program that happens while they are on the job in their various teams, designed to help them continue to grow their overall developer skills and also learn how things work at our company (we're a pretty big enterprise). This was sort of inspired by Facebook's internal bootcamp idea, but it also grew out of the realization that we were not set up to take in juniors without some kind of structure that ensured they were provided guaranteed support to keep growing into their roles, since the teams across our department (of ~500 people) have such different focus. This program exposes all of them to the different facets of being a front-end and back-end developer, no matter what team they are on. The juniors have 2 to 4 sessions per week on different tech topics, with courses taught by volunteers from within the department who sign up to prepare the course and present it. The program has a been a huge success (both for the juniors and for the more experienced folks giving the courses), and we are starting our 3rd cohort this month. When we opened the job posting to take applications this year, we got 450 applications in 3 days, for 10 possible positions. I wish we could expand the program to take in more people but we've found that 10 is what we can handle for now.
- beepbooptheory 4y ago

29athrowaway 4y ago

> Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own (or with minimal feedback) for 5 years. I learned 10x more coding C++ and Rust in my room, watching Twitch streams of people doing interesting things and watching Cppcon talks than many years of coding in other languages at work. > Disorganized or messy code isn’t the same as technical debt. Try fixing a production problem at 4 AM and having to read some messy code. It will make you think "why did something think it is acceptable to have this in a mission critical system?". Try having to maintain a critical feature in a non-breaking manner and having to deal with some messy code. It is frustrating. So, messy code is unprofessional. It's bad workmanship.

sbarre 4y ago
>> Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own (or with minimal feedback) for 5 years. > I learned 10x more coding C++ and Rust in my room, watching Twitch streams of people doing interesting things and watching Cppcon talks Exactly! You had a whole team supporting you, asynchronously.
hazz99 4y ago
Off-topic, but what streams! Would love to follow along with some interesting Rust ones.
- 29athrowaway 4y ago
  Mostly streams about competitive programming, security, OS development, programming language development and game development. Streamers in these categories come and go. On Twitch you can find the developers of the zig and jai programming languages, the developers of Factorio, top competitors from codeforces, and all sort of interesting projects. Ocassionally there are university professors, security researchers, etc.

mikewarot 4y ago

I've never had my code reviewed. The majority of my code was written in the days of MS-DOS, Turbo Pascal, and eventually Windows and Delphi. I was the solo developer at a small firm in the Chicago area with one product, which I had written. As a retired person, I think it's like skydiving, something I'll never do. Unless of course, something on my github takes off.

sidlls 4y ago

The point about over documenting is okay, but reliance on automation and tests is completely separate from documentation. They serve different purposes. The code is not (all of) the documentation. People who rely on code comments, API docstrings/comments, and tests as documentation are thinking of documentation only at the level of the interface, not the bigger picture: that's a junior mentality. Also, documentation becomes stale and unreliable because too often too little attention is paid to it. It's not as fun as writing code, and it's arguably harder since the audience is either non-technical or has a different area of technical expertise.

KaiserPro 4y ago

> 5. Everything must be documented!!!! I mean it should > Focus on automation over documentation where appropriate. Tests or other forms of automation are less likely to go out of sync. So instead I try to focus on writing good tests with clear language, so developers working on code I wrote are able to see how the project functions with working code. This makes me uneasy. I don't want to pick on OP, because its a common enough opinion. However both is best. I don't think people really read tests to understand code, normally because tests are so contrived and shit they they are a burden to be ignored.

corrral 4y ago
> However both is best. I don't think people really read tests to understand code, normally because tests are so contrived and shit they they are a burden to be ignored. I have read tests for this kind of reason, but usually in codebases without static types. I consider static types mostly a form of machine-verifiable and tool-friendly documentation.

superb-owl 4y ago

The meta-lesson here is that considering certain truths to be "absolute" is harmful. The greatest asset you can have as a programmer is flexibility. Understand the tradeoffs (e.g. tech debt vs over-engineering, thorough testing vs shipping quickly) and navigate them intelligently, rather than dogmatically pushing everything to one side of the tradeoff.

Jemm 4y ago

Senior developer at 21 is part of the problem with software now. Companies only want to hire young people but those hires have very little life skill or knowledge outside of their field. They arrive with vim for the latest and greatest shunning the tried and true. Yes architectures need to evolve, of course, but it isn't evolution. It is flavour of the generation with new trumping functionality and usability in many cases. The author does mention the importance of a mentor and I completely agree with that. I think mentor should be a job title with extra perks, rather than someone who is 4 years older than you who knows where the best espresso machine is. Grump.

newfie_bullet 4y ago

Really enjoyable read. I'm in a software mentoring role now and definitely going to share this with new devs - always important to recognize just how much you don't know and being too rigid in your thinking can really hinder things.

stakkur 4y ago

>So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. In my experience, this is the norm, not the exception. Especially in certain areas like 'web development'. Everybody talks about tests and nods sagely in their direction--but I've rarely encountered some kind of meaningful test harness.

jnash 4y ago

Wow. What a refreshingly smart developer. Somebody who is smart enough to question their own believes and learn from it. It is so rare to meet somebody like that. Kudos!

phibz 4y ago

I see people get tech debt wrong. I've heard it called sorts of things. My current team thinks it's easy tasks, 1 pointers. I've seen it called sysadmin work that isn't business focused. In my opinion tech debt is the result of a choice. Tech debt is the remainder of a solution modulo good enough. You choose to do something you consider less than perfect with the understanding that you're just delaying some of the work until later. That left over work is Tech debt. For example, we need to implement auth on our web app, but let's hard code the permissions and do RBAC later. That's hard and not really valuable with such a limited feature set. RBAC in your web app is therefore Tech debt.

mattkenefick 4y ago

This is like.. a list of things to avoid doing.

waltermartinez 4y ago

Wass good good with it .

devnull3 4y ago

Small piece of wisdom I received when I was an intern: "Never get sentimental with your code"

LandR 4y ago
I get paid to write code, I couldn't care less if it's deployed or not. If they pay me to write it, and it doesn't get used, that's their waste of money / time, not mine.
Nimitz14 4y ago
Applies to many things, Stephen King on writing: "You have to be willing to kill your darlings."
seer 4y ago
While this is indeed a very good advice, I learned how to cope with this a little better than “just don’t care”. Mostly because I do enjoy coding, and am still sentimental with code I’ve written decades ago. The trick is to split that kind of code into their own libraries. Preferably open sourced. This way once your code has outlived its usefulness to your current project it can still live on, and be useful somewhere else. For example one of the first things I’ve written as a jquery plugin that I really liked, I polished it, wrote some docs and demos, and in its day it was pretty cool (stayed on HN homepage for two days). I still got mentioned for it years later by people actually using it even now. Even if I myself don’t find it useful at all, it’s still nice to see it is used by someone somewhere.
mypastself 4y ago
I’ve had customers request complete rebuilds of functionalities several times over, destroying weeks of effort each time… and I’ve never cared, as long I’ve clearly communicated my concerns beforehand. I’m precious about the code only while developing it. The process is the fulfilling part to me, not how the end result is used. The approach has its drawbacks, I’m sure, but I find it very easy to not grieve over paid-for-but-unused work.
augustk 4y ago
As long as the code is versioned you don't completely kill your checked in darlings.

DougMellon 4y ago

> Good enough is good enough. I’ve only been in my first role for about two months and this one hit the hardest for me personally. I imagine it has a direct correlation with impostor syndrome, but I spend a lot of time writing things over and over again because in the back of my mind I’m thinking “is this the correct approach? Will they think I’m failing if it’s not how they’d do it?” I consider myself lucky that I’m in a position with a great team that’s very helpful but I struggle to balance the line of when to ask questions - which often stems from not trusting myself to be to their standard.

dgb23 4y ago
That’s actually great. You are playing and exploring, which will definitely lead to deeper skills. It’s not impostor syndrome, it’s just realizing where you are and putting in the time to improve. It’s only an issue if you stress out too much over it, or if you spend too much time doing it. Maybe schedule a time for this type of work, like 1h a day, or 3h. Really depends on the type of work you’re doing and what the circumstances are.
phil-martin 4y ago
It's a hard one to learn in the first 5 or 10 years or so I think. For me the correct approach is the one that solves the problem, feels good enough for the user (with varying definitions of good enough depending on the business goals), and doesn't create a maintenance headache. There is a large amount of room in there for correct solutions.
ZephyrBlu 4y ago
I also had the problem of not wanting to ask questions and look stupid, and my manager told me to ask the questions I need to get the task done. Very simple and effective. Also, instead of re-writing things in solitary many times over it would be a lot more effective to write something pretty good (In your eyes) and then ask for feedback on it. That way you can either validate that you're doing a good job, or start to learn what "good" looks like.
- sigstoat 4y ago

camjohnson26 4y ago

The truth I had to unlearn is that coding is a solitary activity, and that coding is the most important part of a senior software engineer’s job. Now I rarely have the chance to code for a few hours straight because if I have enough information to write code then all that’s left is the easy part. The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. Not to mention onboarding newer devs who haven’t learned the technologies yet.

AtNightWeCode 4y ago
Where I live the worst of this is that one is often expected to be the head of a team as well as lead developer. Sitting in meetings with people talking about personal matters was not the reason I became a developer. The purpose of having autonomous teams with agile development is to speed up development by defining responsibility between different roles in the team and to give the team a sense of ownership that will enable quick decisions and shorter time to production. Scrum for instance also emphasis the need for protecting the developers from the outside. But in this agile post apocalypse it seems like the result have become the opposite.
- chrisweekly 4y ago
  Yeah, I keep seeing this enterprisey top-down centralized micromanaging cargo-cult "digital transformation" so-called "Agile" rigid overspecified prescriptive process conveniently ignore the crucial SELF-ORGANIZING TEAMS aspect of the original manifesto.
taylodl 4y ago
Yep. Coding is a team sport. When hiring, think more along the lines like you're drafting for an NFL team. How does the potential hire's talents complement the team's? Will the personalities and the way they work fit with the team's? You ignore team culture at your own peril and that's been true now for decades.
temac 4y ago
It depends on tons of factors. Yes there are things besides designing and coding, and they can be harder depending on people and projects, but some strong links to the technical parts are always needed, in the sense that a manager is not an evolution of an engineer. Cutler wrote non negligible parts of NT. Linus doesn't "code" much anymore but still has an enormous technical impact. Limiting the dichotomy to "coding" vs anything else is really weird because coding is just a part of design, and never should have been considered the absolutely only essential part of software engineering -- and that's the case regardless of your seniority. Otherwise you can as well be considered a kind of secretary with additional specialized skills. Even if you don't recognize the other activities you are still doing them, at least temporarily in your head even when working on a project alone. And also there are tons of areas where code/design can still be tricky even for highly talented people. E.g. writing a state of the art compiler is not necessarily easy even when the problem has been well defined.

oconnor663 4y ago

> Things like indendetation, formatting, naming – god forbid you did it differently than I would have. I agree with chilling out about this when it's a human making the changes...except now that we have autoformatters we can actually be more pedantic about this than ever before :) If the autoformatter doesn't agree with what you wrote, bam, red CI. > Everyone writes tests A big thing I've learned over the years is that making your code testable often takes more foresight and experience than actually writing the tests. "What's the right way to test this?" becomes an important question when starting something new. And "Can we make it easier to test this?" becomes an important question when inheriting something.

latch 4y ago
This is why a lot of people don't test or claim that testing takes more time since "we spend half our time fixing the tests" - a lack the experience to design code that's testable. I think it's also worth pointing out that up to a point, code that's testable tends to be more maintainable. This largely has to do with coupling and cohesion. Code that's hard to test in indicative of too much coupling and/or not enough cohesion. This pendulum can swing too far the other way though. I hate when relatively straightforward code is made more complicated in the name of testing (often comes up when dealing with non deterministic sources of data, such as the current time). But this, in my opinion, is a comparatively small problem. 100% you should test private functions if it makes sense. Whether something is public or not has no bearing on the value you'll derive from testing. If anything, sometimes you can avoid real headache by focusing specifically on the private function (by definition, the private function has to be more focused than the public function calling it). Also, we should probably all be fuzzing more.
- deleted 4y ago
  [deleted]
- tziki 4y ago
  >I think it's also worth pointing out that up to a point, code that's testable tends to be more maintainable. This largely has to do with coupling and cohesion. Code that's hard to test in indicative of too much coupling and/or not enough cohesion. I feel like whenever someone complains that the code is hard to test, there's always someone who's quick to claim that it's just indicative of problems with the code itself, rather than an issue with writing tests. This rings false to me. Making code testable is simply one aspect that you need to take into consideration when writing code, along with readability, extensibility, modifiability etc. If you remove one of those constraints, it often becomes easier to focus on optimizing for the other constraints. I don't believe that adding testability as a constraint somehow makes the code better - more often, it just forces you to write the code in a certain way which feels 'logical' when considering the constraint of testability, but makes it harder to optimize the other constraints. The feeling of 'revelation' when you end up needing to modify code to make it more testable is mostly just the constraints imposed onto the code.

jehlakj 4y ago

For me, it was that I thought that being a good programmer was that I write clean code with enough abstraction and indirection to make it future proof. Boy I was wrong. Unless you’re doing the same thing you’ve done for years, you can’t tell the future. And just when your unnecessary abstraction is wrong, this the reason why we’re talking about tech debt in the first place. Because nobody wants to touch it. Unfortunately, I didn’t have anyone to tell me this for the longest time. It wasn’t until I had to fix a bug for something I wrote in the past, and I couldn’t figure out just what I wrote. Now I try to write dumb and simple (yet sensible) code until there’s a good reason for abstractions. I have nothing to prove at this point in my career.

snarf21 4y ago
Well said. We are having a similar "fight" where I work now. Way too much premature optimization. I think the one concept that takes a while to really understand is to focus on separation of concerns. It is far too easy to get encapsulation wrong. People (imo) generally forget to apply the SoC test that tells them where to draw the line. We also have a lot of parallel development where re-factoring a View (Screen) could cause a rippling failure to other people's code. Too often they try to reuse everything instead of the important part of extracting the shared business logic into a XXManager and letting the Views just be dumb. Who cares if two Views developed in parallel might be too similar? It might change in the future and don't have to worry about 1 View doing 2 jobs.
li2uR3ce 4y ago
> Now I try to write dumb and simple (yet sensible) code until there’s a good reason for abstractions. Good abstraction is a lot harder than most think. We tote abstraction's benefits as a reason for abstraction but fail to recognize bad abstraction and how it completely negates any would be benefit. Too often abstraction (so called) requires a lot of research into how it's implemented. By the time you figure out enough implementation details to use the abstraction, you could have implemented it yourself quicker. It saves no time or effort but you're stuck with it because existing code is hard to part with. If you're not reliving your users of a shit ton of implementation details then it's just not good abstraction. Code for someone who doesn't want or have time to learn the details. Often this will be your future self despite your current believe that your mind is a steal trap and would never forget how you did this stuff.

pvg 4y ago

Discussion at the time, 516 comments: https://news.ycombinator.com/item?id=20124018 https://news.ycombinator.com/item?id=20124018

monksy 4y ago

Bad developers and companies have little to no testing. Yes, it's fairly common out there. Doesn't make it right.

tornato7 4y ago

I still reminisce about the first big project I ever built. As an intern I was told high level what to do and given two years alone in a room working eight hours a day to figure out how to build it, zero guidance from anyone. I didn’t really have any concept of importing libraries or using open source software, so literally every part of this huge and complex application was custom-written by me. All UI elements were custom designed from shape primitives, including a full time series graphing utility and a drag-and-drop programming language with compiler. The database was built by me using a custom binary data format I had invented and lots of disk IO. It was extremely fragile, but it was also the most beautiful and functional app I have ever used to date. I wish it weren’t a Java applet so I could host it on the web again, but alas.

confidantlake 4y ago
This is awesome. I often think I would be a better developer if I had something like this when I was first starting out. Alas, 95% of my experience is gluing libraries together to check off Jira tickets.
puchatek 4y ago
What year was this?
smt88 4y ago
> it was also the most beautiful and functional app I have ever used to date I laughed at this because of course a software developer would think the best-ever UX is the one they built in complete isolation with exactly 1 user (who happpened to also be the developer and designer).
- baobabKoodaa 4y ago
  I see your point, but I would give GP the benefit of doubt. Their app might be more beautiful and more functional than you think!
bilekas 4y ago
This seems to be the extreme opposite though of other posts with badly structured responsibilities. As a senior I will always rely on having a set of eyes or other opinions and viewpoints. Its invaluable! I wonder if you went back to the source code now would you feel the same about its brilliance! :)

LAC-Tech 4y ago

I deployed by ssh-ing into a server and running git pull. That sounds wonderful. Let's do that again.

gjulianm 4y ago
There's a reason most deployments moved away from that: - Sometimes you need more complex actions to update a service than just "update the code". Migration scripts, dependent services restarts... - It's fine on one server, but the more you have the more difficult it gets - Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. - Too easy to say "let me just modify this thing here in production" and end up with bug fixes that are only applied on certain machines and certain versions... I get the "let's do things in a simple way again" sentiment, but it's not like the complexity is there because people like complexity.
- feoren 4y ago
  > Too easy to say "let me just modify this thing here in production" This sounds crazy to me, like saying "it's too easy to say 'let me just poop on the floor right here' instead of going to the bathroom properly". What!? I can sorta vaguely understand why someone might think that's a little easier in the moment, but someone who has that little control of themselves needs serious help, if not a good old-fashioned kick out the door. That is not a technology problem, it's a human problem -- and a major one.
  - gjulianm 4y ago
    The reality is that those things happen. Technology must inevitably deal with human problems too, it isn’t as easy as saying “just don’t do that thing”.
    - LAC-Tech 4y ago
- 4y ago

chasil 4y ago

I'll just repost these thoughts by Dave Cutler, designer of the kernels for Windows NT/XP(...) and (Open)VMS: “I have a couple of sayings that are pertinent. The first is: ‘Successful people do what unsuccessful people won’t.’ The second is: ‘If you don’t put them [bugs] in, you don’t have to take them out.’ I am a person that wants to do the work. I don’t want to just think about it and let someone else do it. When presented with a programming problem, I formulate an appropriate solution and then proceed to write the code. While writing the code, I continually mentally execute the code in my head in an attempt to flush out any bugs. I am a great believer in incremental implementation, where a piece of the solution is done, verified to work properly, and then move on to the next piece. In my case, this leads to faster implementation with fewer bugs. Quality is my No. 1 constraint – always. I don’t want to produce any code that has bugs – none. “So my advice is be a thinker doer,” Cutler concluded. “Focus on the problem to solve and give it your undivided attention and effort. Produce high-quality work that is secure.” https://news.microsoft.com/features/the-engineers-engineer-computer-industry-luminaries-salute-dave-cutlers-five-decade-long-quest-for-quality/ https://news.microsoft.com/features/the-engineers-engineer-c...

deleted 4y ago
[deleted]

deleted 4y ago

[deleted]

DeathArrow 4y ago

>In reflecting on this first decade of getting regularly paid money to type weird symbols into my Terminal, I wanted to take some time to share some of the ways my thinking shifted over the years as a developer. I think that's a very low take of what means being a developer. I am not getting payed for that, I'm getting payed for solving problems. Some easy, some hard, some very hard.

DeathArrow 4y ago

>I learned all that fancy Angular-specific JSDoc syntax. My code was always twice as long because it had so much documentation and so many comments That's a very bad habit. Code should be self documenting. If you need to write comments to explain what the code does, you've done a poor job at writing it.

Spixel_ 4y ago
Comments aren't bad per se, but they should explain Why vs. How.

fzeroracer 4y ago

For me, one of the things I learned early on is that there are a lot of salesmen in the software world that want to sell you something. Whether its tooling, methodology, classes or whatever. Cargo culting is rampant and everyone wants to sell you their version of a hammer to nail down any problems with your software. This doesn't make them necessarily wrong or not have valuable things to bring to the table but much like everything else you should be careful not to fall into the trap of assuming that it works for them, therefore it works for you.

dzikimarian 4y ago

What I learned is that, there is no absolute truths in this line of work. There are only tools and techniques, which can be applied depending on the context. Some of them fit 99% of times. Some almost never. None is written in stone and any of them won't make project good or bad on its own, let alone commercially successful. You become senior, when thrown into a new environment, you can can say which of these will help to move forward, and you know that not because "everyone does that", but you truly understand what they will do to the project and the team.

dgb23 4y ago
That’s the essence of the post. Every “absolute truth” is more of a talking point that is relativized and leads to more insightful and grounded comments and learnings.

brunooliv 4y ago

One more thing not in the article is that sometimes, leadership or whoever is responsible for the roadmap, can FAIL to do their due diligence and you can end up a few months working on something meant to be "a great product" just to realize after it ships, that the customer just isn't buying it.

tobyhinloopen 4y ago

Cmon guys just write some damn tests. It’s not that hard

dgb23 4y ago
The keyword is “some”. In web dev there are things that lend themselves to automated testing, for example domain logic. There, it is often most beneficial and most helpful during development. Start with that, it won’t save time if you don’t. Other things, like UI, I think are best tested manually and visually. This takes a ton of time but leads to the highest quality and confidence.
pojzon 4y ago
Its very easy to force ppl to write tests. For example Sonar QualityGate on new code added to the code base. Its hard to make ppl write tests that make sense and are worth running.

jollybean 4y ago

This is well written. There list should be longer.

wronglyprepaid 4y ago

Many good points and a great article overall, though one that i think is possibly most overlooked is: > Having some technical debt is healthy

unnouinceput 4y ago

Quote 1: "Next year, I’ll be entering my 10th year of being formally employed to write code. Ten years! And besides actual employment, for nearly 2/3 of my life, I’ve been building things on the web. " Math: If 2/3 => 10, then 3/3 => X. X = 3/3 * 10 div 2/3; X = 30/2; X = 15. So the author is 15 years old and writing code since 5 years old, and during this time he was also employed. Unusual but not unheard to be employed as a child. Quote 2: "I was 19 years old when I applied for my first technical job. The position I was applying for was called “Student Webmaster”." Oaw there, we just calculated she's 15 so how was she 19 when first employed? Something's off on one of above quotes.

mypastself 4y ago
Besides employment. So like the rest of us, she likely coded before she started doing it professionally. I don’t think your “2/3 => 10” equation is supported by the quote. Seems pretty clear she started building things at 9 or 10, and got her first job a decade later.

Lapsa 4y ago

I deliberately skip the semicolons