31 ms·

Things I’ve learned in 20 years of programming

531 points by galfarragem 7y ago

turk73 7y ago
Going on about 17 years here. It's not looking great for the future in terms of staying a developer. It's getting harder to find reasonable jobs anymore. My current one and the last one are/were disappointments. I think the best words of advice are: Devise a career backup plan. I don't currently have one even though I have exerted effort in that direction. Probably end up a stocker at Home Depot or something. Hope not. At some point, knowing another language or framework may be interesting to you, but it is pretty much immaterial unless you are going to use it on that job. For instance, I love Kotlin, but there's no Kotlin developer roles in my market hardly. Waste of time. Same thing happened with Clojure. I never learn. You will be too expensive: I recently went after a Kafka Architect role which I should have been a slam dunk for but when it got to price the other side suddenly got all wobbly, excuses appeared, and poof, it disappeared. Companies want cheap, throw away talent. I will say it again: Companies want cheap, throw away talent.
- theonething 7y ago
  Would you comment on what made your current and last jobs disappointments? I don't even know what the baseline is for satisfying programming jobs. All my jobs have been similar in terms of points of frustration.[0] I've just kind of accepted it as normal. [0] I would elaborate but don't have time right now. At work.
  - cr0sh 7y ago
    > I don't even know what the baseline is for satisfying programming jobs. For myself, it's always been about the team I was a part of. When you are part of a team that takes pride in their work, and they perform well together, supporting each other, learning from each other, etc - no "prima donnas", and they all have fun doing it - it leads to a good day of work. I'm lucky in that for most places I have worked - from the first shop that took me in, to my current employer - this has been the case. I can only think of a couple of places I worked where that wasn't entirely the case; both came with excess politics, and other stress that I just didn't (and still don't) understand. I stuck out with it at both, but I'm glad I'm no longer a part of either. One thing I do know and understand - this comes from someone who started their software engineering career when they were 18 years old, and now I'm pushing 50 - every place I have worked that I have had this "good team quality" has been a small employer, usually with fewer than 50 employees. My current position, there are fewer than 20 employees. No - I don't make, have never made, and likely never will make "FAANG" money - but I'm not stressed either, and I make enough to keep a roof over my family's head, the lights on, and food in the pantry. I'm content, and if an opportunity comes up for a FAANG-money type position - I will have to look long and hard at it, before making that leap - because I feel that it might come with costs that just don't make sense to me any longer. I'd rather have a more "basic" salary and little stress, than a lot of money but stress out the door due to a myriad of reasons in such a workplace. That isn't to say that's inevitable, but I've just found that as the employers I've worked for were larger, the less my satisfaction with going in and the job overall.
    - away_throw 7y ago
      I'm just entering the field (19-yo), and I don't have an particular experience in the field yet. From people I've talked to, jobs that you describe are the best options. I'm particularly interested in government jobs for these reasons.
      - wolco 7y ago
        At 19 work everywhere. Startups can offer so much value at your stage with freedom if you choose right.
    - JMTQp8lwXL 7y ago
      Can you be certain FANG jobs have more stress? Some rules inarguably would, but I hear of more people doing the standard 9-5 at FANGs than anything else. They do quality work, they do it in a reasonable amount of time, and they spend the rest of their non-working hours on other things in life.
- Diederich 7y ago
  Seven different organizations have been paying me (in part) to write code since 1993. > Companies want cheap, throw away talent. I've read and heard about this, and I think it's probably true in many or most cases, but I haven't had this problem in my career. I'm better compensated now than I ever have been, and when I want to move, it's easier than ever to get a good position. A little bit of context: most of my professional career was in the south and midwestern US, but the last decade has been in the San Francisco bay area. Also, while I've always been a software engineer, I've always worked more on the 'operational' side, often called 'devops', 'SRE' or 'production engineer' these days. I wish you the best going forward.
- hinkley 7y ago
  I wonder if there's space for some boutique shops that specialize in sobriety.
- deleted 7y ago
  [deleted]
bungie4 7y ago
The stack is to deep. Nothing is easy anymore. The technology count is staggering. I'm close to retirement. I'm looking forward to pursuing my personal programming interests while I work some mundane, no responsibility, minimum wage job. Programming is a ridiculous career path.
- deanmoriarty 7y ago
  It is indeed ridiculous. I am in my early 30s and I am aggressively saving as much as I can while living very frugally, to hopefully retire multi-millionaire abroad or get a lower paid job that won't stress the life out of me before I turn 40. Hopefully I won't become unemployed before hitting my target, or die of a stress-related heart attack. I am not completely disappointed about my career choice because it allowed me to save a lot of money (see note), but boy, it is an insanely ridiculous career. Very frequently I wish I pursued something else, there is just way too much and fresh new crap keeps coming, every week. Can you believe 4 years ago almost nobody was talking about containers/Kubernetes? Just to name a random niche. Can you imagine what will happen in a couple years? They say "it's all the same, it's a cycle, you already learned it": that might be true if you are a manager or a PM and you just need a very superficial overview of the ecosystem, but if you are a senior engineer you need to master your craft, so even if a technology has been reinvented you need to spend hundreds of hours learning the details of this new incarnation, that's literally what your employer expects. Ask an engineer if being proficient with VMWare is enough to get up to speed with Kubernetes just because one is the sequel in the virtualization scene... exactly. Also add the effect of globalization: my company hires talent from Eastern Europe (not consultants, entire teams with local management, product, ...) who produce insanely high quality software products at a ridiculous pace, exquisitely documented. Those people are wicked smart and on top of that work 20 hours a day. I am surprised software engineers are still hired in the US, where working 10 hours a day is already considered unhealthy. I feel the same way as a brick and mortar store that's going to get pushed out of business because of the more efficient and cheaper Amazon. Note: It also helps that I choose to live in the super expensive Bay Area while not wanting kids, so I don't have the same spending requirements of people with kids and can bank the spread that most people would have to spend on schooling, nannies, good housing, ... I rent a studio for $2k in a ghetto-ish area, and that's 70% of my expenses. If I had a couple kids for whom I needed to provide good housing, nannies and private schools, I would be spending all I earn and there wouldn't even be an end in sight to this madness.
wintorez 7y ago
Regarding avoiding copy-paste; I'm a JavaScript developer, and from time to time, I run `npx jsinspect src` in the root of my projects to detect copy-paste. The results are always interesting.
- picod 7y ago
  cool, if this is reliable enough to be part of CI process it will be super useful
  - wintorez 7y ago
    Never ran into a problem with it myself but ¯\_(ツ)_/¯
- dehrmann 7y ago
  I've got slightly mixed feeling on copy-paste because sometimes it leads to lots of dependencies--some with conflicts--and you would have been better off writing if (s != null && !s.isEmpty()
arduinomancer 7y ago
When people say TDD does that imply writing unit tests before writing code? Or do they just mean doing unit tests as you code? I'm never sure when I hear this term because the benefits described (thing's just working first try) seem to apply no matter what order do it in.
- kazinator 7y ago
  Hopefully, when people say "TDD", they refer to the very specific methodology by that name which goes something like this: before making each change, writing a test which fails, and then making it pass with the minimal amount of code, followed by refactoring which keeps all tests passing. No, not exactly unit tests.
- auspex 7y ago
  TDD means writing tests before code At a very high level: Write the most basic case and it will fail (no code written). Write code so the test passes. Now write another test that will fail. Then write code so that tests passes. It forces you to write code in a way that is testable and you catch any regressions if previous tests fail. In the end... you shouldn't.... write any code that isn't required to pass a test.
  - kohtatsu 7y ago
    I figured the value of TDD was to settle on the higher-level functions and APIs before dealing with the nitty gritty.
- gt2 7y ago
  Some people take liberty with the term, but in general it's failing test first, write code to make it pass, as in the development is driven by the test like the term sounds: 'test driven development'.
- devnonymous 7y ago
  As a veteran (20+ years) programmer I've yet to witness a project where tests are written before the code for the entire duration of the implementation. I personally feel TDD is the snake oil you need to sell to get your team to do write unit tests for max coverage.
bitpow 7y ago
> Learn yourself some TDD. You won’t regret it. How?
- erikpukinskis 7y ago
  You can start here: https://martinfowler.com/bliki/TestDrivenDevelopment.html https://martinfowler.com/bliki/TestDrivenDevelopment.html
- thijsvandien 7y ago
  J.B. Rainsberger's course is what eventually did it for me, after reading about TDD a lot but never managing to put it into practice: https://tdd.training https://tdd.training.
- mettamage 7y ago
  Thank you everyone for contributing resources! I am slowly learning testing and I found it weird how there aren't many good resources. I'm favoriting this comment so I can get back to this later.
- cjfd 7y ago
  Read the book. Worked for me.
  - cjfd 7y ago
    And after you read the book do a simple toy project to try it out.
algaeontoast 7y ago
Do you / commenters here really “enjoy” programming as a career as much as when they first had enough skill and enthusiasm to build things? I think this is a big misconception among devs with less than five years of exp.
- faanghacker 7y ago
  I started programming when I was 11. Taught myself C++ from that age. Solved tons of tough problems in personal and school projects before going into industry at age 22. Now at 35, I definitely think it's time to move on. I won't lie about my lack of interest in the field. The problems are less difficult to solve, but also much more frustrating. A lot more black boxes that you can't reverse engineer when you get stuck. Working with other people in a big company means things move far slower than my ability to get things done. Plus the proliferation of different tech stacks means that despite the big job market, most of the new jobs require specific knowledge that I don't have, and my existing experience with low level coding and problem solving don't carry much weight.
  - randomidiot666 7y ago
    > Plus the proliferation of different tech stacks means that despite the big job market, most of the new jobs require specific knowledge that I don't have, and my existing experience with low level coding and problem solving don't carry much weight. None of those jobs _require_ specific knowledge upfront. The problem is clueless fuckwits in HR filtering out CVs based on keywords. General problem solving ability and knowledge of fundamentals means you can actually learn any of the latest shitty frameworks in a few hours on the job.
  - CheesecakeFred 7y ago
    >The problems are less difficult to solve, but also much more frustrating. A lot more black boxes that you can't reverse engineer when you get stuck. Working with other people in a big company means things move far slower than my ability to get things done. The part about black boxes you get stuck on strongly resonates with me. Programming can be a lot of fun, when you can rely on your own, or well documented programming. But enter the world of development in big companies where everything specification never leaves alpha phase, is done in retrospect, only on request, 3 month later then needed and if missing half of the absolutely needed information is the best case, it's just so miserable.
RhysU 7y ago
There's some silly Moore's law variant buried here: The programmer demand will double every couple of years.
Antoninus 7y ago
I was very lucky that my first job out of school was at a Perl shop with older, senior engineers. It felt like I hit the jackpot in mentorship. I learned more with my two years with them than the next 5 where I cycled through all the trendy frameworks and devops tools. I’m hoping to find another small, experienced shop like that and where I can give my next 10 years; willing to relocate and take a pay cut.
- mettamage 7y ago
  How do you find those though?
  - Antoninus 7y ago
    As a new developer, I'd frequent a lot of meetups to build my network. I always made a point to talk the oldest guys in the room as the conversation was always the most interesting. I happen to be a sucker for dot-com bubble war stories.
dev12778765 7y ago
One more advice for young programmers is - make the effort and learn the domain you are programming in. If you are writing finance software - use the opportunity and learn finance/accounting. If you writing retail software, learn about retail. If doing some network automation - learn about networking. I neglected this early on and picked up only enough needed to complete my programming tasks. Now regret this as could have ended up with more options across industries I worked in. Even maybe start your own business if you become expert in some domain.
apatheticonion 7y ago
What about copy/pasting interfaces between packages to avoid cross package dependencies
johnwheeler 7y ago
I’ve been programming professionally for 20 years too.. What I’ve learned is there’s no end to the “architects”, “mentors”, “coaches”, “team leaders” and “know it alls” who want to condescend and tell me how to do my job. 20 years of programming has taught me to avoid working with people who take themselves so seriously and think they’ve figured it all out. 20 years has taught me the importance of compromise, give-and-take, and following as much as leading. It’s also taught me that there are people who’ve only been doing this for half as long that are 10 times better.
- deleted 7y ago
  [deleted]
- jdsalaro 7y ago
  If I would have more than one up-vote to give you, I definitely would. Although I have less professional experience than you, around 6 years combined in software development and information security, I've also come to appreciate people who find the right balance of taking what they do seriously without being uptight about it. Which brings me to a trait that almost always puts a dent on my respect for anyone regardless of seniority: not asking enough questions and being quick to make statements. I loathe this so much that I've turned the opposite into my work mantra: "no statements until there've been enough questions". IMHO, this "small" tweak changes one's interactions and their outcomes with other co-workers for the better.
- MrBuddyCasino 7y ago
  > there’s no end to the “architects”, “mentors”, “coaches”, “team leaders” and “know it alls” who want to condescend and tell me how to do my job Shame I can only upvote this once. Avoid like the plague. B Players, natural vs institutional authority etc.
- purple_ducks 7y ago
  Don't forget the self-described "thought-leaders". Oh you've been ~programming for ~3 years and you're now a thought leader - fantastic delusion.
  - deleted 7y ago
deleted 7y ago
[deleted]
carl_sandland 7y ago
This is not the best advice I've ever read, some of it smacks of "silver bullet" thinking. For example, it's sometimes better to duplicate than couple. Within the same component sure don't copy pasta. Also I think TDD is frankly ridiculous; I've seen many teams spending more money on gold-plating test lines of code than actual code. I've seen other, better teams spend all their efforts on full integration testing only. There are no golden rules, it's just hard work.
- dogcomplex 7y ago
  You're in good company with Jonathan Blow and, it appears, John Carmack. Teams pushing TDD might be a good smell test for whether they know how to efficiently code.
  - carl_sandland 7y ago
    If I was arrogant enough to consider myself a good programmer after 30 years of doing it, I would suggest as humbly as possible, that perhaps TDD is something better coders can do in their heads and 'skip over'. How do we know what API to build ? Because the code needs it. How we know the code works ? Because I just ran it.
    - kbenson 7y ago
      Which comes right back around to the idea of who you're writing code for. I suspect much, possibly most, of the time it's not purely for yourself, but for your team, or other Co tributes to the project, or thr person that has your job a few years from now, or even you a few years from now. Just because you have the entire system in your head right now, will you when you revisit it a year later to add a feature or fix a big? How much time will it take to internalize completely? Tests allow you to know less about the system overall and still make assured changes to smaller portions of it because prior you (or someone else) has spent the extra time to make sure any mistakes are caught early and easily. The go-to counter to this is that you should really know what you're doing and understand the system you're working in, but that's often not only infeasible, but impossible for one person (how well do you know all the libraries you're using?). There are plenty of codebase out there where I think no one person can internalize it all and understand it well enough to always make food choices, and since you'll have to choose what you want to remember, a helpful tool to make sure you don't violate some important facets of how it works is useful. Now, much of this is about testing in general, but if you think about it, there's a lot similar about writing new code and coming into a large chunk of code that you need to alter but you have limited understanding of or poor recollection of. The same things that keep you from violating how it should function help your design a coherent functionality in the first place.
dchichkov 7y ago
Started coding in 1988. What I've learned, it seems, that there are many styles. That they are worth learning. They are part of the art we practice. There are rules that these styles bring. And compromises. Zen of Python. The exceptional beauty of John Carmack. Rebases of Google Style. Dive into a Linux Kernel. Very Objective Apple Style. Infinite pains of TensorFlow. Simple magic of SQL. Clarity of PyTorch. Unique ways of Prolog. Formality of Antlr. Frictionless Microsoft Style. Completeness of Theano. Abstract Syntax Notation One. Eldritch style of Michael Abrash.
- specialist 7y ago
  Ditto methodologies. Maybe analogous to mixed strategy equilibria from game theory.
randomsearch 7y ago
Started coding in 1987. Have no idea what I’m doing. Regularly panic about how little I must know. Can’t figure out if people giving advice and writing books are genuinely a lot better than me, or just more confident.
- WrtCdEvrydy 7y ago
  It's very funny... I bet you have no problems explaining complex problems to the Junior and Senior developers, and receive high marks for knowing highly technical details. I wonder if there is a correlation between amount of knowledge and Impostor syndrome kinda like the four stages of competence. At the beginning, you may think you know a lot but as you get further along, there's less and less confidence that comes with more knowledge.
- rlonn 7y ago
  Haha, same here (but I started -81-82). Love programming but get my kicks out of running code in production, not written code in a repo, so I'm always in a hurry to ship and usually don't have time to learn the new, shiny tech and practises. Which makes me feel out of date, ignorant, impostor:ish. But then I realise (or tell myself?) that I'm shipping working functionality way faster than most, and that I can't be so bad. I think.
zvrba 7y ago
Some of the things "I've learned in 25 years": After arguing with a friend who claimed to have discovered a bug in `malloc` because his program crashed (that was a long time ago), I figured that there's a hierarchy of probable causes of bugs, from most probable: 1. The code I wrote [you must understand only your code] 2. A 3rd-party library/dependency [you must understand your dependencies] 4. The compiler [you must understand the compiler-generated code] 5. The OS, or OS-provided library [You must be intimately familiar with OS internals] 6. CPU, or other hardware-related [You must be intimately familiar with how the CPU or other HW works] It's basically arranged according to how many other programs are using the given facilities. Returning to the "buggy malloc", I did not dismiss his theory outright just pointed out that if malloc were bugged in such an elementary fashion, that no other programs could work, hence there was overwhelming probability of his code being bugged, not malloc. --- Just like security features, error-handling cannot be bolted on afterwards. Robust programs begin with defining error-handling strategies and expected outcomes in case of errors and building the rest on top. --- I could probably go on, but... meh.
- faanghacker 7y ago
  LOL reminds me of the time at work when I was helping a fellow SWE deploy his code to a new platform. It didn't work. He immediately blamed the it on the fact that we were using a new platform. I then noticed that we were also deploying a newer version of his code onto this new platform, instead of the old code that was known to work on the old platform. I asked him how he knew it was because of the platform (#5 or #6) and not the newer version of his code (#1). Turned out I was right. And this was his code, not mine. The best part? He had been on the team longer than I had, and this was at Google of all places. And people wonder why I have lost interest in the field...
- dchichkov 7y ago
  And sometimes. Yes. It is just a bug in a malloc. And you can fix it. And it wouldn't be there any more. And cool thing, you can even brag a bit that you've fixed bug in a malloc. By the way, there was sort of a bug in a malloc I remember fixing. Now, when was it. Ah, on 7th October 2006 ;) https://gitlab.flux.utah.edu/gtw/git/blob/dff9d65dc61af8a00a6eef153ebc59b76de9c412/compat/nedmalloc/Readme.txt https://gitlab.flux.utah.edu/gtw/git/blob/dff9d65dc61af8a00a...
beagle3 7y ago
The “no copy pasta” requirement leads to left-pad incidents.
carl_sandland 7y ago
Some things I've learned after 35 years; 1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice. 2. question all assumptions. 3. there is no silver bullet (read mythical man month). 4. fight complexity and over-engineering : get to your next MVP release. 5. always have a releasable build (stop talking and start coding). 6. code has little value in of itself; only rarely is a block of code reusable in other contexts. 7. requirements are a type of code, they should be written very precicely. 8. estimation is extrapolation (fortune telling) with unknown variables of an unknown function. 9. release as frequently as possible, to actual users, so you can discover the actual requirements. 10. coding is not a social activity.
- metters 7y ago
  Could you please elaborate the "coding is not a social activity" or offer a reference. Thank you very much in advance! reply
  - carl_sandland 7y ago
    np. The "Stuff" that surrounds coding is very social (point 1), but the actual activity of writing code is very inward focused and ideally uninterrupted. The idea of FLOW is a very real thing, its very zen: hours just fade away until you look up and everyone has gone to lunch. I'm tilting at the open office windmill and idea that whilst I'm actually coding, I need to interact with others. Being a "Developer" (planning, designing) is very social, however writing the actual code, for me at least, is a very inward activity and suits my quiet personality. The problem here is that non-coders don't understand this and it can cause a lot of friction when working in the usual group office environment. It's a catch 22, people want me to code for them, but then they have a problem with me socially when I'm trying to code ;)
    - metters 7y ago
      I agree with that and can also relate to this point (as I experience exactly this in my current project) my colleague already complained about being interrupted many times already. The problem is that the non coding colleagues want to ask just a 'quick question'. Thanks for the quick reply.
neilwilson 7y ago
I just wish I knew as much now as I thought I did 35 years ago.
cryptica 7y ago
I like TDD but it should be adapted to the project. For some projects, I only do integration tests, for others, I only write the unit tests for one or a few of the more complex modules and test the whole system manually then if needed I will add more tests later after the project code has settled. It depends on a lot of things; such as what kind of complexity the project's modules are prone to (algorithmic complexity or integration complexity), team size, security requirements and reliability requirements. It's very important to keep the testing as minimal as possible at the beginning. Sometimes minimal means a lot, but you need to be able to justify it because tests (especially unit tests) lock down interfaces and functionality and this can go against agile principles. If your project is innovative and requires that agility. After 15 years experience coding on many different projects and companies, what I learned is that blanket statements are often unhelpful. You need to critically evaluate every case as unique and make arguments about why and how your case differs from the norm (and it usually does).
- mixmastamyk 7y ago
  Agreed, I don’t write a lot of tests until happy with the design. When that solidifies it’s time to get cracking on the unit tests.
  - Flemlord 7y ago
    I have a variant on this. I start with a bullet-list of functionality I think I’ll need. Then I write one test each for items that could impact my architectural choices. Once I finish that first pass I go back and flesh out each item with multiple tests as necessary. Flushing out the architecture early is the trickiest part for me. Occasionally I miss a seemingly-simple feature that ends up requiring an architecture change. If this happens late in the process, I may pay for the oversight with hours of refactoring.
curiousfiddler 7y ago
From my ~15 years of experience, if there is just one advice I could give to someone starting their career as a software developer: irrespective of whether your work is exciting or not as much, it is a joy in itself to keep working on improving your craft, which is writing software systems. Excellence is always a moving target, but if you stop working on your craft, the joy you will experience as you become senior and older, will keep decreasing.
- specialist 7y ago
  Nice. The way I heard it from an English professor: Writers write. The only way to become a better writer is to write more.
- 0x445442 7y ago
  This is my experience as well. At this point in my career, craft and quality is about the only thing that keeps me from ejecting.
Dowwie 7y ago
The one point in this article that I will challenge relates to duplication of logic. The moment you've come across two similar scenarios that on the surface may benefit by a refactor and consolidation of logic, don't just instinctively jump to it. Refactoring to a universal model can take a great deal of time and effort. Days, if not weeks, may pass before your universal design is ready. Consider the cost of time and effort. Others are waiting for this work to be finished. Time is not on your side. Make sure you have a damn good business justification for consolidating designs and fight your biases. I am advocating for knowing the costs and benefits of your refactoring decisions. If you can't predict what the costs are, take that as an indicator that maybe you should avoid refactoring, just yet. Consider as a litmus test discussing costs and benefits with people whom it will affect and try to reach an agreement. If you dread the thought of having that discussion, you probably ought to avoid refactoring. If you can't argue in favor of your refactoring idea, it's not worth the effort. Also, consider that just because you can re-use flexible designs doesn't mean you will. You may not be the best person to consider the probability of re-use. Assume that it's unlikely: YAGNI (you ain't gonna need it).
Kiro 7y ago
I've worked in multiple systems where we've needed country-specific DoX() and you always end up completely separating them. You start trying to fit one core logic for all countries but it always gets reduced into nothing and you wish you had just copypasted the first country logic to the next to begin with. Once everything is separated you feel much more comfortable introducing that specific Mexico change without messing around with the core logic. Of course things that are truly agnostic shouldn't be duplicated but that tends to be extremely narrow in the end and you never know what it is before you have a lot of countries. It quickly becomes a maintenance nightmare trying to fit broad logic to impossible flexibility.
bsaul 7y ago
Things i’ve learned after 20 years : - understand and care about context. Understand the input and output of what you’re developing. Why people need it to function a certain way. And how people are actually going to use it. - business trumps tech (most of the time). Not just in matter of how well a company will perform financially, but also in everyday developer life. For example : a different business model may imply a different tech stack choice (and that’s just one example). Understand and care about the business side of the place you’re working in. It’ll also helps you greatly communicating with your managers.
z3t4 7y ago
What relates to me is when he was gonna write how awful TDD is, then he actually tried it - and liked it! There are so many things we think are utterly stupid, but have never even tried.
patrec 7y ago
Is there a single example of a notable great programmer who uses TDD?
- cateye 7y ago
  Martin Fowler is an example.
  - patrec 7y ago
    What makes you think so? Have you seen any great code he has produced or are you aware of him having implemented something decidedly non-trivial? I might be wrong, but my impression is that he's someone who spends almost all his time telling people how to write software, not writing it.
yahyaheee 7y ago
From the creator of TDD on why TDD doesn’t work in many highly innovative environments https://softwareengineeringdaily.com/2019/08/28/facebook-engineering-process-with-kent-beck/ https://softwareengineeringdaily.com/2019/08/28/facebook-eng...
solidist 7y ago
https://twitter.com/dougarcuri/status/1198217546362753025 https://twitter.com/dougarcuri/status/1198217546362753025
kamaal 7y ago
1. Interview skills >>>>>> Job skills, productivity, and ability to get work done. 2. Learn office politics and learn to do it well. 3. Everything else is irrelevant.
TravelAndFood 7y ago
"Do you know what correlates more than anything else with undesirable codebase properties? The size of the codebase." Well yeah, more code means more bad code. I'm interested to know whether more code means proportionally more bad code. If not, his statement doesn't mean much.
teddyh 7y ago
“From around the age of six, I had the habit of sketching from life. I became an artist, and from fifty on began producing works that won some reputation, but nothing I did before the age of seventy was worthy of attention. At seventy-three, I began to grasp the structures of birds and beasts, insects and fish, and of the way plants grow. If I go on trying, I will surely understand them still better by the time I am eighty-six, so that by ninety I will have penetrated to their essential nature. At one hundred, I may well have a positively divine understanding of them, while at one hundred and thirty, forty, or more I will have reached the stage where every dot and every stroke I paint will be alive. May Heaven, that grants long life, give me the chance to prove that this is no lie.” — Hokusai
jmilloy 7y ago
I'm at a point where I think that "(2) Code is a liability" is a fundamental revelation that separates developers. It acts as a proxy for so many things, including some from this post: - Code duplication should be avoided, but not if the alternative is complicated or highly-coupled code. Duplicated code is increased liability, and complicated code is increased liability. Sometimes two similar but separate functions is just easier to read, use, test, and maintain; assessing the "liability" helps you make the best decision. - Tests are good because they decrease liability of other code, but they are themselves are a liability, so you can go too far (as many other commenters note about TDD). And "Code is a liability" is not a silver-bullet. It isn't specific or prescriptive enough, and that's a good thing. It requires experience and effort to understand what that means and to make use of it on a case by case basis. But I think it does point you in the right direction by posing the right questions and focusing on the important trade-offs.
- house9-2 7y ago
  > Code duplication should be avoided, but not if the alternative is complicated or highly-coupled code. 100% agree. Along these lines, avoid applying DRY principles to "incidental duplication"; You can end up coupling completely unrelated code if you are blinded by removing all duplication.
  - Ma8ee 7y ago
    This is so important! You must have separate functions, even if they contain the exact same code, if they are semantically different.
deleted 7y ago
[deleted]
bbbobbb 7y ago
Does anybody have some words of wisdom / articles / tutorials / books on TDD for your typical web applications? I am asking because for me, writing tests before the code is a natural choice for pure functions where I can easily map inputs to outputs. I cannot imagine writing that kind of code without tests. But the usual task is gluing together tons of components and 3rd party calls (e.g. starting from an HTTP request, doing some transformations, calling some APIs maybe, persisting stuff in the database). All of this depends on tons of side effects and hard to mock components. The only test I can write there easily is a full contract that mapping the HTTP request to HTTP response. This doesn't help me with developing the internals (definitely not TDD), it only verifies the end result. Even worse if there is no clear response but the result is piped into some queue over the network or something similar. I am either completely incompetent or I develop applications that are tons of hard to test stuff (especially with simple unit tests) with only tiny core of functionality that seems easy to test.
- dakom 7y ago
  Here's a few ideas on testing web apps: 1. The internal pure data representation. If you're using some state management like redux or xstate then you can just cache the state on changes and run tests as-is (e.g. running the tests would be sending events and then checking that the state is what you expect it to be). 2. The page itself. Tools like Selenium and Cypress will allow you to easily inspect and run tests against the DOM state (e.g. running the tests would be emulating interactions with the page and checking that the properties of elements are what you expect them to be) 3. Checking the virtual dom (or other middleware). For example, with React, you can "get at" its internal data (at least the level you need) via a testing framework like Enzyme. 4. If your app uses webgl context or is simply too hard to test on any of the above "pure data" levels, you need some sort of image recognition to compare pixels. I doubt this is going to be _perfectly_ testable but you can try your hand at Sikuli or roll your own with OpenCV
rsmckinney 7y ago
10 years of coding in trade for 10 years of middle management... why would I follow your coding advice? A serious question.
CheesecakeFred 7y ago
Point 2. "Code is a Liability" ends with the sentence: "Always strive to do everything using as little code as humanly possible." On its own I consider this bad advice. I would change it to 'Always strive to make your code as easy to understand as possible, while less lines of code and complexity is preferred'
mcovey 7y ago
First one was an immediate turn-off. Duplicating code once is fine. With the given example, there's no need to start building an abstract billing method and a data structure to encapsulate the differences in billing between different countries, because there are only two countries and one is new. Wait for a pattern to emerge before refactoring, especially when such refactoring will make the code more complex and harder to reason about.

531 points by galfarragem 7y ago

Going on about 17 years here. It's not looking great for the future in terms of staying a developer. It's getting harder to find reasonable jobs anymore. My current one and the last one are/were disappointments. I think the best words of advice are: Devise a career backup plan. I don't currently have one even though I have exerted effort in that direction. Probably end up a stocker at Home Depot or something. Hope not. At some point, knowing another language or framework may be interesting to you, but it is pretty much immaterial unless you are going to use it on that job. For instance, I love Kotlin, but there's no Kotlin developer roles in my market hardly. Waste of time. Same thing happened with Clojure. I never learn. You will be too expensive: I recently went after a Kafka Architect role which I should have been a slam dunk for but when it got to price the other side suddenly got all wobbly, excuses appeared, and poof, it disappeared. Companies want cheap, throw away talent. I will say it again: Companies want cheap, throw away talent.

theonething 7y ago
Would you comment on what made your current and last jobs disappointments? I don't even know what the baseline is for satisfying programming jobs. All my jobs have been similar in terms of points of frustration.[0] I've just kind of accepted it as normal. [0] I would elaborate but don't have time right now. At work.
- cr0sh 7y ago
  > I don't even know what the baseline is for satisfying programming jobs. For myself, it's always been about the team I was a part of. When you are part of a team that takes pride in their work, and they perform well together, supporting each other, learning from each other, etc - no "prima donnas", and they all have fun doing it - it leads to a good day of work. I'm lucky in that for most places I have worked - from the first shop that took me in, to my current employer - this has been the case. I can only think of a couple of places I worked where that wasn't entirely the case; both came with excess politics, and other stress that I just didn't (and still don't) understand. I stuck out with it at both, but I'm glad I'm no longer a part of either. One thing I do know and understand - this comes from someone who started their software engineering career when they were 18 years old, and now I'm pushing 50 - every place I have worked that I have had this "good team quality" has been a small employer, usually with fewer than 50 employees. My current position, there are fewer than 20 employees. No - I don't make, have never made, and likely never will make "FAANG" money - but I'm not stressed either, and I make enough to keep a roof over my family's head, the lights on, and food in the pantry. I'm content, and if an opportunity comes up for a FAANG-money type position - I will have to look long and hard at it, before making that leap - because I feel that it might come with costs that just don't make sense to me any longer. I'd rather have a more "basic" salary and little stress, than a lot of money but stress out the door due to a myriad of reasons in such a workplace. That isn't to say that's inevitable, but I've just found that as the employers I've worked for were larger, the less my satisfaction with going in and the job overall.
  - away_throw 7y ago
    I'm just entering the field (19-yo), and I don't have an particular experience in the field yet. From people I've talked to, jobs that you describe are the best options. I'm particularly interested in government jobs for these reasons.
    - wolco 7y ago
      At 19 work everywhere. Startups can offer so much value at your stage with freedom if you choose right.
  - JMTQp8lwXL 7y ago
    Can you be certain FANG jobs have more stress? Some rules inarguably would, but I hear of more people doing the standard 9-5 at FANGs than anything else. They do quality work, they do it in a reasonable amount of time, and they spend the rest of their non-working hours on other things in life.
Diederich 7y ago
Seven different organizations have been paying me (in part) to write code since 1993. > Companies want cheap, throw away talent. I've read and heard about this, and I think it's probably true in many or most cases, but I haven't had this problem in my career. I'm better compensated now than I ever have been, and when I want to move, it's easier than ever to get a good position. A little bit of context: most of my professional career was in the south and midwestern US, but the last decade has been in the San Francisco bay area. Also, while I've always been a software engineer, I've always worked more on the 'operational' side, often called 'devops', 'SRE' or 'production engineer' these days. I wish you the best going forward.
hinkley 7y ago
I wonder if there's space for some boutique shops that specialize in sobriety.
deleted 7y ago
[deleted]

bungie4 7y ago

The stack is to deep. Nothing is easy anymore. The technology count is staggering. I'm close to retirement. I'm looking forward to pursuing my personal programming interests while I work some mundane, no responsibility, minimum wage job. Programming is a ridiculous career path.

deanmoriarty 7y ago
It is indeed ridiculous. I am in my early 30s and I am aggressively saving as much as I can while living very frugally, to hopefully retire multi-millionaire abroad or get a lower paid job that won't stress the life out of me before I turn 40. Hopefully I won't become unemployed before hitting my target, or die of a stress-related heart attack. I am not completely disappointed about my career choice because it allowed me to save a lot of money (see note), but boy, it is an insanely ridiculous career. Very frequently I wish I pursued something else, there is just way too much and fresh new crap keeps coming, every week. Can you believe 4 years ago almost nobody was talking about containers/Kubernetes? Just to name a random niche. Can you imagine what will happen in a couple years? They say "it's all the same, it's a cycle, you already learned it": that might be true if you are a manager or a PM and you just need a very superficial overview of the ecosystem, but if you are a senior engineer you need to master your craft, so even if a technology has been reinvented you need to spend hundreds of hours learning the details of this new incarnation, that's literally what your employer expects. Ask an engineer if being proficient with VMWare is enough to get up to speed with Kubernetes just because one is the sequel in the virtualization scene... exactly. Also add the effect of globalization: my company hires talent from Eastern Europe (not consultants, entire teams with local management, product, ...) who produce insanely high quality software products at a ridiculous pace, exquisitely documented. Those people are wicked smart and on top of that work 20 hours a day. I am surprised software engineers are still hired in the US, where working 10 hours a day is already considered unhealthy. I feel the same way as a brick and mortar store that's going to get pushed out of business because of the more efficient and cheaper Amazon. Note: It also helps that I choose to live in the super expensive Bay Area while not wanting kids, so I don't have the same spending requirements of people with kids and can bank the spread that most people would have to spend on schooling, nannies, good housing, ... I rent a studio for $2k in a ghetto-ish area, and that's 70% of my expenses. If I had a couple kids for whom I needed to provide good housing, nannies and private schools, I would be spending all I earn and there wouldn't even be an end in sight to this madness.

wintorez 7y ago

Regarding avoiding copy-paste; I'm a JavaScript developer, and from time to time, I run `npx jsinspect src` in the root of my projects to detect copy-paste. The results are always interesting.

picod 7y ago
cool, if this is reliable enough to be part of CI process it will be super useful
- wintorez 7y ago
  Never ran into a problem with it myself but ¯\_(ツ)_/¯
dehrmann 7y ago
I've got slightly mixed feeling on copy-paste because sometimes it leads to lots of dependencies--some with conflicts--and you would have been better off writing if (s != null && !s.isEmpty()

arduinomancer 7y ago

When people say TDD does that imply writing unit tests before writing code? Or do they just mean doing unit tests as you code? I'm never sure when I hear this term because the benefits described (thing's just working first try) seem to apply no matter what order do it in.

kazinator 7y ago
Hopefully, when people say "TDD", they refer to the very specific methodology by that name which goes something like this: before making each change, writing a test which fails, and then making it pass with the minimal amount of code, followed by refactoring which keeps all tests passing. No, not exactly unit tests.
auspex 7y ago
TDD means writing tests before code At a very high level: Write the most basic case and it will fail (no code written). Write code so the test passes. Now write another test that will fail. Then write code so that tests passes. It forces you to write code in a way that is testable and you catch any regressions if previous tests fail. In the end... you shouldn't.... write any code that isn't required to pass a test.
- kohtatsu 7y ago
  I figured the value of TDD was to settle on the higher-level functions and APIs before dealing with the nitty gritty.
gt2 7y ago
Some people take liberty with the term, but in general it's failing test first, write code to make it pass, as in the development is driven by the test like the term sounds: 'test driven development'.
devnonymous 7y ago
As a veteran (20+ years) programmer I've yet to witness a project where tests are written before the code for the entire duration of the implementation. I personally feel TDD is the snake oil you need to sell to get your team to do write unit tests for max coverage.

bitpow 7y ago

> Learn yourself some TDD. You won’t regret it. How?

erikpukinskis 7y ago
You can start here: https://martinfowler.com/bliki/TestDrivenDevelopment.html https://martinfowler.com/bliki/TestDrivenDevelopment.html
thijsvandien 7y ago
J.B. Rainsberger's course is what eventually did it for me, after reading about TDD a lot but never managing to put it into practice: https://tdd.training https://tdd.training.
mettamage 7y ago
Thank you everyone for contributing resources! I am slowly learning testing and I found it weird how there aren't many good resources. I'm favoriting this comment so I can get back to this later.
cjfd 7y ago
Read the book. Worked for me.
- cjfd 7y ago
  And after you read the book do a simple toy project to try it out.

algaeontoast 7y ago

Do you / commenters here really “enjoy” programming as a career as much as when they first had enough skill and enthusiasm to build things? I think this is a big misconception among devs with less than five years of exp.

faanghacker 7y ago
I started programming when I was 11. Taught myself C++ from that age. Solved tons of tough problems in personal and school projects before going into industry at age 22. Now at 35, I definitely think it's time to move on. I won't lie about my lack of interest in the field. The problems are less difficult to solve, but also much more frustrating. A lot more black boxes that you can't reverse engineer when you get stuck. Working with other people in a big company means things move far slower than my ability to get things done. Plus the proliferation of different tech stacks means that despite the big job market, most of the new jobs require specific knowledge that I don't have, and my existing experience with low level coding and problem solving don't carry much weight.
- randomidiot666 7y ago
  > Plus the proliferation of different tech stacks means that despite the big job market, most of the new jobs require specific knowledge that I don't have, and my existing experience with low level coding and problem solving don't carry much weight. None of those jobs _require_ specific knowledge upfront. The problem is clueless fuckwits in HR filtering out CVs based on keywords. General problem solving ability and knowledge of fundamentals means you can actually learn any of the latest shitty frameworks in a few hours on the job.
- CheesecakeFred 7y ago
  >The problems are less difficult to solve, but also much more frustrating. A lot more black boxes that you can't reverse engineer when you get stuck. Working with other people in a big company means things move far slower than my ability to get things done. The part about black boxes you get stuck on strongly resonates with me. Programming can be a lot of fun, when you can rely on your own, or well documented programming. But enter the world of development in big companies where everything specification never leaves alpha phase, is done in retrospect, only on request, 3 month later then needed and if missing half of the absolutely needed information is the best case, it's just so miserable.

RhysU 7y ago

There's some silly Moore's law variant buried here: The programmer demand will double every couple of years.

Antoninus 7y ago

I was very lucky that my first job out of school was at a Perl shop with older, senior engineers. It felt like I hit the jackpot in mentorship. I learned more with my two years with them than the next 5 where I cycled through all the trendy frameworks and devops tools. I’m hoping to find another small, experienced shop like that and where I can give my next 10 years; willing to relocate and take a pay cut.

mettamage 7y ago
How do you find those though?
- Antoninus 7y ago
  As a new developer, I'd frequent a lot of meetups to build my network. I always made a point to talk the oldest guys in the room as the conversation was always the most interesting. I happen to be a sucker for dot-com bubble war stories.

dev12778765 7y ago

One more advice for young programmers is - make the effort and learn the domain you are programming in. If you are writing finance software - use the opportunity and learn finance/accounting. If you writing retail software, learn about retail. If doing some network automation - learn about networking. I neglected this early on and picked up only enough needed to complete my programming tasks. Now regret this as could have ended up with more options across industries I worked in. Even maybe start your own business if you become expert in some domain.

apatheticonion 7y ago

What about copy/pasting interfaces between packages to avoid cross package dependencies

johnwheeler 7y ago

I’ve been programming professionally for 20 years too.. What I’ve learned is there’s no end to the “architects”, “mentors”, “coaches”, “team leaders” and “know it alls” who want to condescend and tell me how to do my job. 20 years of programming has taught me to avoid working with people who take themselves so seriously and think they’ve figured it all out. 20 years has taught me the importance of compromise, give-and-take, and following as much as leading. It’s also taught me that there are people who’ve only been doing this for half as long that are 10 times better.

deleted 7y ago
[deleted]
jdsalaro 7y ago
If I would have more than one up-vote to give you, I definitely would. Although I have less professional experience than you, around 6 years combined in software development and information security, I've also come to appreciate people who find the right balance of taking what they do seriously without being uptight about it. Which brings me to a trait that almost always puts a dent on my respect for anyone regardless of seniority: not asking enough questions and being quick to make statements. I loathe this so much that I've turned the opposite into my work mantra: "no statements until there've been enough questions". IMHO, this "small" tweak changes one's interactions and their outcomes with other co-workers for the better.
MrBuddyCasino 7y ago
> there’s no end to the “architects”, “mentors”, “coaches”, “team leaders” and “know it alls” who want to condescend and tell me how to do my job Shame I can only upvote this once. Avoid like the plague. B Players, natural vs institutional authority etc.
purple_ducks 7y ago
Don't forget the self-described "thought-leaders". Oh you've been ~programming for ~3 years and you're now a thought leader - fantastic delusion.
- deleted 7y ago

deleted 7y ago

[deleted]

carl_sandland 7y ago

This is not the best advice I've ever read, some of it smacks of "silver bullet" thinking. For example, it's sometimes better to duplicate than couple. Within the same component sure don't copy pasta. Also I think TDD is frankly ridiculous; I've seen many teams spending more money on gold-plating test lines of code than actual code. I've seen other, better teams spend all their efforts on full integration testing only. There are no golden rules, it's just hard work.

dogcomplex 7y ago
You're in good company with Jonathan Blow and, it appears, John Carmack. Teams pushing TDD might be a good smell test for whether they know how to efficiently code.
- carl_sandland 7y ago
  If I was arrogant enough to consider myself a good programmer after 30 years of doing it, I would suggest as humbly as possible, that perhaps TDD is something better coders can do in their heads and 'skip over'. How do we know what API to build ? Because the code needs it. How we know the code works ? Because I just ran it.
  - kbenson 7y ago
    Which comes right back around to the idea of who you're writing code for. I suspect much, possibly most, of the time it's not purely for yourself, but for your team, or other Co tributes to the project, or thr person that has your job a few years from now, or even you a few years from now. Just because you have the entire system in your head right now, will you when you revisit it a year later to add a feature or fix a big? How much time will it take to internalize completely? Tests allow you to know less about the system overall and still make assured changes to smaller portions of it because prior you (or someone else) has spent the extra time to make sure any mistakes are caught early and easily. The go-to counter to this is that you should really know what you're doing and understand the system you're working in, but that's often not only infeasible, but impossible for one person (how well do you know all the libraries you're using?). There are plenty of codebase out there where I think no one person can internalize it all and understand it well enough to always make food choices, and since you'll have to choose what you want to remember, a helpful tool to make sure you don't violate some important facets of how it works is useful. Now, much of this is about testing in general, but if you think about it, there's a lot similar about writing new code and coming into a large chunk of code that you need to alter but you have limited understanding of or poor recollection of. The same things that keep you from violating how it should function help your design a coherent functionality in the first place.

dchichkov 7y ago

Started coding in 1988. What I've learned, it seems, that there are many styles. That they are worth learning. They are part of the art we practice. There are rules that these styles bring. And compromises. Zen of Python. The exceptional beauty of John Carmack. Rebases of Google Style. Dive into a Linux Kernel. Very Objective Apple Style. Infinite pains of TensorFlow. Simple magic of SQL. Clarity of PyTorch. Unique ways of Prolog. Formality of Antlr. Frictionless Microsoft Style. Completeness of Theano. Abstract Syntax Notation One. Eldritch style of Michael Abrash.

specialist 7y ago
Ditto methodologies. Maybe analogous to mixed strategy equilibria from game theory.

randomsearch 7y ago

Started coding in 1987. Have no idea what I’m doing. Regularly panic about how little I must know. Can’t figure out if people giving advice and writing books are genuinely a lot better than me, or just more confident.

WrtCdEvrydy 7y ago
It's very funny... I bet you have no problems explaining complex problems to the Junior and Senior developers, and receive high marks for knowing highly technical details. I wonder if there is a correlation between amount of knowledge and Impostor syndrome kinda like the four stages of competence. At the beginning, you may think you know a lot but as you get further along, there's less and less confidence that comes with more knowledge.
rlonn 7y ago
Haha, same here (but I started -81-82). Love programming but get my kicks out of running code in production, not written code in a repo, so I'm always in a hurry to ship and usually don't have time to learn the new, shiny tech and practises. Which makes me feel out of date, ignorant, impostor:ish. But then I realise (or tell myself?) that I'm shipping working functionality way faster than most, and that I can't be so bad. I think.

zvrba 7y ago

Some of the things "I've learned in 25 years": After arguing with a friend who claimed to have discovered a bug in `malloc` because his program crashed (that was a long time ago), I figured that there's a hierarchy of probable causes of bugs, from most probable: 1. The code I wrote [you must understand only your code] 2. A 3rd-party library/dependency [you must understand your dependencies] 4. The compiler [you must understand the compiler-generated code] 5. The OS, or OS-provided library [You must be intimately familiar with OS internals] 6. CPU, or other hardware-related [You must be intimately familiar with how the CPU or other HW works] It's basically arranged according to how many other programs are using the given facilities. Returning to the "buggy malloc", I did not dismiss his theory outright just pointed out that if malloc were bugged in such an elementary fashion, that no other programs could work, hence there was overwhelming probability of his code being bugged, not malloc. --- Just like security features, error-handling cannot be bolted on afterwards. Robust programs begin with defining error-handling strategies and expected outcomes in case of errors and building the rest on top. --- I could probably go on, but... meh.

faanghacker 7y ago
LOL reminds me of the time at work when I was helping a fellow SWE deploy his code to a new platform. It didn't work. He immediately blamed the it on the fact that we were using a new platform. I then noticed that we were also deploying a newer version of his code onto this new platform, instead of the old code that was known to work on the old platform. I asked him how he knew it was because of the platform (#5 or #6) and not the newer version of his code (#1). Turned out I was right. And this was his code, not mine. The best part? He had been on the team longer than I had, and this was at Google of all places. And people wonder why I have lost interest in the field...
dchichkov 7y ago
And sometimes. Yes. It is just a bug in a malloc. And you can fix it. And it wouldn't be there any more. And cool thing, you can even brag a bit that you've fixed bug in a malloc. By the way, there was sort of a bug in a malloc I remember fixing. Now, when was it. Ah, on 7th October 2006 ;) https://gitlab.flux.utah.edu/gtw/git/blob/dff9d65dc61af8a00a6eef153ebc59b76de9c412/compat/nedmalloc/Readme.txt https://gitlab.flux.utah.edu/gtw/git/blob/dff9d65dc61af8a00a...

beagle3 7y ago

The “no copy pasta” requirement leads to left-pad incidents.

carl_sandland 7y ago

Some things I've learned after 35 years; 1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice. 2. question all assumptions. 3. there is no silver bullet (read mythical man month). 4. fight complexity and over-engineering : get to your next MVP release. 5. always have a releasable build (stop talking and start coding). 6. code has little value in of itself; only rarely is a block of code reusable in other contexts. 7. requirements are a type of code, they should be written very precicely. 8. estimation is extrapolation (fortune telling) with unknown variables of an unknown function. 9. release as frequently as possible, to actual users, so you can discover the actual requirements. 10. coding is not a social activity.

metters 7y ago
Could you please elaborate the "coding is not a social activity" or offer a reference. Thank you very much in advance! reply
- carl_sandland 7y ago
  np. The "Stuff" that surrounds coding is very social (point 1), but the actual activity of writing code is very inward focused and ideally uninterrupted. The idea of FLOW is a very real thing, its very zen: hours just fade away until you look up and everyone has gone to lunch. I'm tilting at the open office windmill and idea that whilst I'm actually coding, I need to interact with others. Being a "Developer" (planning, designing) is very social, however writing the actual code, for me at least, is a very inward activity and suits my quiet personality. The problem here is that non-coders don't understand this and it can cause a lot of friction when working in the usual group office environment. It's a catch 22, people want me to code for them, but then they have a problem with me socially when I'm trying to code ;)
  - metters 7y ago
    I agree with that and can also relate to this point (as I experience exactly this in my current project) my colleague already complained about being interrupted many times already. The problem is that the non coding colleagues want to ask just a 'quick question'. Thanks for the quick reply.

neilwilson 7y ago

I just wish I knew as much now as I thought I did 35 years ago.

cryptica 7y ago

I like TDD but it should be adapted to the project. For some projects, I only do integration tests, for others, I only write the unit tests for one or a few of the more complex modules and test the whole system manually then if needed I will add more tests later after the project code has settled. It depends on a lot of things; such as what kind of complexity the project's modules are prone to (algorithmic complexity or integration complexity), team size, security requirements and reliability requirements. It's very important to keep the testing as minimal as possible at the beginning. Sometimes minimal means a lot, but you need to be able to justify it because tests (especially unit tests) lock down interfaces and functionality and this can go against agile principles. If your project is innovative and requires that agility. After 15 years experience coding on many different projects and companies, what I learned is that blanket statements are often unhelpful. You need to critically evaluate every case as unique and make arguments about why and how your case differs from the norm (and it usually does).

mixmastamyk 7y ago
Agreed, I don’t write a lot of tests until happy with the design. When that solidifies it’s time to get cracking on the unit tests.
- Flemlord 7y ago
  I have a variant on this. I start with a bullet-list of functionality I think I’ll need. Then I write one test each for items that could impact my architectural choices. Once I finish that first pass I go back and flesh out each item with multiple tests as necessary. Flushing out the architecture early is the trickiest part for me. Occasionally I miss a seemingly-simple feature that ends up requiring an architecture change. If this happens late in the process, I may pay for the oversight with hours of refactoring.

curiousfiddler 7y ago

From my ~15 years of experience, if there is just one advice I could give to someone starting their career as a software developer: irrespective of whether your work is exciting or not as much, it is a joy in itself to keep working on improving your craft, which is writing software systems. Excellence is always a moving target, but if you stop working on your craft, the joy you will experience as you become senior and older, will keep decreasing.

specialist 7y ago
Nice. The way I heard it from an English professor: Writers write. The only way to become a better writer is to write more.
0x445442 7y ago
This is my experience as well. At this point in my career, craft and quality is about the only thing that keeps me from ejecting.

Dowwie 7y ago

The one point in this article that I will challenge relates to duplication of logic. The moment you've come across two similar scenarios that on the surface may benefit by a refactor and consolidation of logic, don't just instinctively jump to it. Refactoring to a universal model can take a great deal of time and effort. Days, if not weeks, may pass before your universal design is ready. Consider the cost of time and effort. Others are waiting for this work to be finished. Time is not on your side. Make sure you have a damn good business justification for consolidating designs and fight your biases. I am advocating for knowing the costs and benefits of your refactoring decisions. If you can't predict what the costs are, take that as an indicator that maybe you should avoid refactoring, just yet. Consider as a litmus test discussing costs and benefits with people whom it will affect and try to reach an agreement. If you dread the thought of having that discussion, you probably ought to avoid refactoring. If you can't argue in favor of your refactoring idea, it's not worth the effort. Also, consider that just because you can re-use flexible designs doesn't mean you will. You may not be the best person to consider the probability of re-use. Assume that it's unlikely: YAGNI (you ain't gonna need it).

Kiro 7y ago

I've worked in multiple systems where we've needed country-specific DoX() and you always end up completely separating them. You start trying to fit one core logic for all countries but it always gets reduced into nothing and you wish you had just copypasted the first country logic to the next to begin with. Once everything is separated you feel much more comfortable introducing that specific Mexico change without messing around with the core logic. Of course things that are truly agnostic shouldn't be duplicated but that tends to be extremely narrow in the end and you never know what it is before you have a lot of countries. It quickly becomes a maintenance nightmare trying to fit broad logic to impossible flexibility.

bsaul 7y ago

Things i’ve learned after 20 years : - understand and care about context. Understand the input and output of what you’re developing. Why people need it to function a certain way. And how people are actually going to use it. - business trumps tech (most of the time). Not just in matter of how well a company will perform financially, but also in everyday developer life. For example : a different business model may imply a different tech stack choice (and that’s just one example). Understand and care about the business side of the place you’re working in. It’ll also helps you greatly communicating with your managers.

z3t4 7y ago

What relates to me is when he was gonna write how awful TDD is, then he actually tried it - and liked it! There are so many things we think are utterly stupid, but have never even tried.

patrec 7y ago

Is there a single example of a notable great programmer who uses TDD?

cateye 7y ago
Martin Fowler is an example.
- patrec 7y ago
  What makes you think so? Have you seen any great code he has produced or are you aware of him having implemented something decidedly non-trivial? I might be wrong, but my impression is that he's someone who spends almost all his time telling people how to write software, not writing it.

yahyaheee 7y ago

From the creator of TDD on why TDD doesn’t work in many highly innovative environments https://softwareengineeringdaily.com/2019/08/28/facebook-engineering-process-with-kent-beck/ https://softwareengineeringdaily.com/2019/08/28/facebook-eng...

solidist 7y ago

https://twitter.com/dougarcuri/status/1198217546362753025 https://twitter.com/dougarcuri/status/1198217546362753025

kamaal 7y ago

1. Interview skills >>>>>> Job skills, productivity, and ability to get work done. 2. Learn office politics and learn to do it well. 3. Everything else is irrelevant.

TravelAndFood 7y ago

"Do you know what correlates more than anything else with undesirable codebase properties? The size of the codebase." Well yeah, more code means more bad code. I'm interested to know whether more code means proportionally more bad code. If not, his statement doesn't mean much.

teddyh 7y ago

“From around the age of six, I had the habit of sketching from life. I became an artist, and from fifty on began producing works that won some reputation, but nothing I did before the age of seventy was worthy of attention. At seventy-three, I began to grasp the structures of birds and beasts, insects and fish, and of the way plants grow. If I go on trying, I will surely understand them still better by the time I am eighty-six, so that by ninety I will have penetrated to their essential nature. At one hundred, I may well have a positively divine understanding of them, while at one hundred and thirty, forty, or more I will have reached the stage where every dot and every stroke I paint will be alive. May Heaven, that grants long life, give me the chance to prove that this is no lie.” — Hokusai

jmilloy 7y ago

I'm at a point where I think that "(2) Code is a liability" is a fundamental revelation that separates developers. It acts as a proxy for so many things, including some from this post: - Code duplication should be avoided, but not if the alternative is complicated or highly-coupled code. Duplicated code is increased liability, and complicated code is increased liability. Sometimes two similar but separate functions is just easier to read, use, test, and maintain; assessing the "liability" helps you make the best decision. - Tests are good because they decrease liability of other code, but they are themselves are a liability, so you can go too far (as many other commenters note about TDD). And "Code is a liability" is not a silver-bullet. It isn't specific or prescriptive enough, and that's a good thing. It requires experience and effort to understand what that means and to make use of it on a case by case basis. But I think it does point you in the right direction by posing the right questions and focusing on the important trade-offs.

house9-2 7y ago
> Code duplication should be avoided, but not if the alternative is complicated or highly-coupled code. 100% agree. Along these lines, avoid applying DRY principles to "incidental duplication"; You can end up coupling completely unrelated code if you are blinded by removing all duplication.
- Ma8ee 7y ago
  This is so important! You must have separate functions, even if they contain the exact same code, if they are semantically different.

deleted 7y ago

[deleted]

bbbobbb 7y ago

Does anybody have some words of wisdom / articles / tutorials / books on TDD for your typical web applications? I am asking because for me, writing tests before the code is a natural choice for pure functions where I can easily map inputs to outputs. I cannot imagine writing that kind of code without tests. But the usual task is gluing together tons of components and 3rd party calls (e.g. starting from an HTTP request, doing some transformations, calling some APIs maybe, persisting stuff in the database). All of this depends on tons of side effects and hard to mock components. The only test I can write there easily is a full contract that mapping the HTTP request to HTTP response. This doesn't help me with developing the internals (definitely not TDD), it only verifies the end result. Even worse if there is no clear response but the result is piped into some queue over the network or something similar. I am either completely incompetent or I develop applications that are tons of hard to test stuff (especially with simple unit tests) with only tiny core of functionality that seems easy to test.

dakom 7y ago
Here's a few ideas on testing web apps: 1. The internal pure data representation. If you're using some state management like redux or xstate then you can just cache the state on changes and run tests as-is (e.g. running the tests would be sending events and then checking that the state is what you expect it to be). 2. The page itself. Tools like Selenium and Cypress will allow you to easily inspect and run tests against the DOM state (e.g. running the tests would be emulating interactions with the page and checking that the properties of elements are what you expect them to be) 3. Checking the virtual dom (or other middleware). For example, with React, you can "get at" its internal data (at least the level you need) via a testing framework like Enzyme. 4. If your app uses webgl context or is simply too hard to test on any of the above "pure data" levels, you need some sort of image recognition to compare pixels. I doubt this is going to be _perfectly_ testable but you can try your hand at Sikuli or roll your own with OpenCV

rsmckinney 7y ago

10 years of coding in trade for 10 years of middle management... why would I follow your coding advice? A serious question.

CheesecakeFred 7y ago

Point 2. "Code is a Liability" ends with the sentence: "Always strive to do everything using as little code as humanly possible." On its own I consider this bad advice. I would change it to 'Always strive to make your code as easy to understand as possible, while less lines of code and complexity is preferred'

mcovey 7y ago

First one was an immediate turn-off. Duplicating code once is fine. With the given example, there's no need to start building an abstract billing method and a data structure to encapsulate the differences in billing between different countries, because there are only two countries and one is new. Wait for a pattern to emerge before refactoring, especially when such refactoring will make the code more complex and harder to reason about.