39 ms·
What I’ve Learned in 45 Years in the Software Industry
- ChrisMarshallNY 6y agoCool article. That suit...that hair... He doesn’t really deliver any “wise mountaintop guru” stuff, though. Just shows that good old-fashioned common sense is timeless (and distressingly rare).
- Ozzie_osman 6y agoI loved the article too. I mean, the most important wisdom is never "mountaintop guru" insight, it's always simple things that just need to be reinforced and actually observed in practice. It's one thing to say "keep it simple" and a totally other thing to actually be keeping it simple for four decades :)
- breck 6y ago> reinforced Agreed. I'm ~15 years in, and so even though I didn't come across any new ideas here, it's very helpful to hear what a 40 year vet thinks are the most important signals and try and harden those paths in my mind.
- Retric 6y agoI have gotten a lot of advice but sage wisdom is rare. The closest I can think of is: “Expertise isn’t coming up with the perfect solution, expertise is knowing you can get a good enough solution on time.” Frequently you have a fast but risky option and a slow but guaranteed one. It’s fine to work on the fast option, just remember to abandon early enough to still finish in time.
- chasd00 6y agoi can't remember where i read it but "engineering is the science of good enough" has always stuck with me. I'm reading Algorithms to Live By and the section on explore/exploit feels relevant here. At what point do you stop looking for new things and rely on the things you already know. lol I feel like i lack the IQ to connect all the dots but there's something applicable in that section to this discussion. maybe i should re-read it...
- huhtenberg 6y agohttps://outline.com/6GdLnT https://outline.com/6GdLnT
- GrinningFool 6y agoI'm not sure the benefit? Reader mode makes it readable, and it seems like outline.com does some weirdness where it traps history back-navigation.
- huhtenberg 6y agoThe original link wasn't working.
- berkserbet 6y agoGreat insights for someone who is 3 year in, like myself. Key point for me ‘Beware of Lock-In’. Been feeling that lately.
- lrossi 6y agoSomething that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest. This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, deploy and maintain. Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.
- mistrial9 6y agoprofessional interview sign seen at the "interview desk" for work placement at an expensive school for digital creatives: "sit up straight; look the interviewer in the eye; wear presentable clothing; answer the questions asked of you" .. I believe the sign was there because that was not occuring in many cases !
- motogpjimbo 6y agoMy experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. Maybe it's different when you interview at a FAANG company though? I imagine FAANG recruitment is a merciless sausage machine.
- folkhack 6y ago> My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. I'm growing further and further away from this mentality in hiring because the sad truth is most of those folks who come in with "quirks" lack maturity. To me, quirks are "yellow flags" in the interview stage because it means that you're not able to put your own weirdness aside to fit socially when you arguably need to the most. Invariably these same "quirks" come up down the road in the employment with output problems, copping attitude with superiors, weirdness in internal/external meetings, and just general antisocial behavior. I get that we're all in hella demand right now but I'm starting to go back on my, "I'm just hiring for the engineering skill/talent" as an excuse to overlook yellow flags. The other thing is contextually, what are the quirks? If the "quirk" is someone being super shy/timid it doesn't even register on my radar as a problem unless it's extreme... I'm talking about the stereotypical "oh so cute dev quirks" like: not dressing appropriately for an interview, interrupting me/talking over me, talking down to me, comparing their last junior position to being Steve Jobs, being sing-songy, inappropriate jokes in any way/shape/form, getting in arguments with themselves... etc etc. I'm at a point that if you can't act 95% professional in your first interview you're done as you're not capable of being "on".
- supernova87a 6y agoOne of the tenets though, "6. Be Honest and Acknowledge When You Don’t Fit the Role" only is fair to the person if the team/company also follows that advice. If a team or company does not value, or cannot tell, or does not act if someone is incompetent and unfit for a role, then this advice penalizes those who are honest, and rewards those who are good at faking competence. You need to have a structure of integrity within which to operate, in order for honest behavior to be rewarded.
- lainga 6y agoI think it's fair. For me, the penalties and rewards you talk about are outweighed by some countervailing factors outside the realm of career development. Even if your current team isn't honest, the ultimate structure of integrity is your very own.
- marcinzm 6y agoI don't see how your statement disagrees with what he said. He's talking about self-acknowledgement which has nothing directly to do with the organization. For example, if the organization values fake competence and you don't then you need to self-acknowledge that and either start faking it, change the organization or find a new job.
- kazinator 6y agoIt's clear doesn't say "acknowledge it loudly to everyone around you so you get kicked out of the role". He says there is more than one solution (e.g. grow to fit the role), and that it's about having the self-knowledge not to stay in a bad place. If an organization pervasively rewards competence fakers, where will that whole organization be in ten years anyway?
- gwbas1c 6y agoI suspect that "or the role can evolve" implies that some roles come with unrealistic expectations. I see this when I see job postings with a long laundry list of qualifications and responsibilities. I suspect that part of succeeding in such roles is figuring out how to evolve the role to be more reasonable.
- SPBS 6y ago> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now it can happen with frameworks too. Is the author calling Rails as 'lock-in'?
- eloff 6y agoIt is no? It's not easy to rewrite into something else if you need to. With rails the biggest reason you might need to do that is the abysmal performance. You need twenty servers to do the work you could have done with one.
- __jem 6y agoIs it not? Even if it's open source, I would view monolith frameworks as a form of ecosystem lock-in. We use Spring at work and I would certainly describe us as suffering from "lock-in" to the Spring ecosystem.
- mewpmewp2 6y agoIn which case are you not going to lock in building something like that? Even if you opt to go framework-less you are now locked in to whatever you are building.
- codingdave 6y agoThis is somewhat true, but that is why separation of concerns is a best practice. Maybe you do have one piece of the stack "locked in" to Rails, but the rest of the stack can stay in place if you want to move from Rails to a different framework.
- Tainnor 6y agoIn Rails, this is unfortunately somewhat difficult (though not impossible) to achieve due e.g. to the autoloading magic that Rails adds and that can make isolating library code a bit more challenging if you're not aware of some intricate details of Ruby's and Rails's loading behaviours.
- mr-wendel 6y agoStuff I'd add that I think is crucial, and all related to one topic: good writing! 1. Learn to write specs Call it an RFC, call it a PRD, call it whatever. Writing out a plan for any project taking around a week or more is always worth it. Use it to establish scope and priorities. Keep a "Questions" section that you whittle away at as you seek out feedback. Make the body a hierarchy of design tasks and implementation ideas. Track revision history and keep it up-to-date. You now have a great way to get sign-off from peers + management, an execution plan, a task breakdown for ticket management and historical documentation on what happened and why. 2. Be terse Is that email looking a little long? Write a "TL;DR:" section at the top and then see what you can delete. If it's nothing, leave the "TL;DR:". Otherwise you may find you've included a lot of intermediate thinking and people only need to know the conclusions. 3. When learning something new, keep a dedicated list of "this looks like magic!" items Use your "down time" to research items on this list instead of refreshing your favorite news aggregator. Ask your peers and mentors about them. Notice when tangental issues come up and spend a few extra minutes seeing how they're related and how that might yield some easier answers. 4. When you want to ask for help... defer clicking "send" Whether its an IM or email, write it up on the side first. Start with your question and follow-up with what you've already done to walk through finding the answer to save the person the effort of starting from step one or pointing out the obvious thing you overlooked. Often this will lead you to answering your own question. If not, still wait 15-30 minutes (if you can) before sending it and work on something else. In that time you're likely to think of something you overlooked and avoid interrupting anyone.
- sabhiram 6y agoUh oh, hug of death?
- ahstilde 6y agoI've always heard great things about working at BTI360. Two of my friends have had long tenures there (long for software engineering, at least).
- cmrdporcupine 6y agoThis is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems. For one, organizational incompetence when people who were valuable contributors where they were are elevated up into roles where they no longer can apply those skills as effectively (i.e. technical team lead to management or architect) leaving a vacuum below. A form of the Peter Principle I guess, except the individual may have competence in their new role but not be happy, or make the team itself less successful. And most importantly, as he touches on: being asked to 'level up' and told that this is your mission can lead to an unpleasurable career. Either when you do get that promo and then find that you don't enjoy the new responsibilities (but become trapped by the position / upgraded compensation etc.) or when you don't get the promo (or don't try) and find that your value in the eyes of yourself and others seems less. And finally, I think this type of thing can really take hold in places with a highly academic background / focus / origin (like Google, etc.) as it mimics in many ways the grade / peer review achievement structure of academia. And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation. Smaller companies looking to grow/formalize should exercise caution when looking at the rating/performance/promo process @ FAANGs / MS as a model for their own. (I'm at 20-25ish years in the industry, but really feel junior in so many ways when I read the words of veterans like this.)
- mathattack 6y agoYes. The challenge is how to measure individual contributors. It’s easy in Sales, which is why salespeople can do very well without being managers. Harder with engineers, whose work is very interconnected.
- cmrdporcupine 6y agoFor sure. And it's why frankly in my opinion it's very hard to scale software development effectively beyond 25-50 engineers. After that politics and faux-meritocracies take over as people lose personal touch with each other. Not that small companies can't be hell, too.
- animex 6y agoPoint 0) Always put your blog on scalable infrastructure in-case you get /slashdotted or Hugger Newsed to death. ^_^
- dmch-1 6y agothat engineers don't get laid.
- dmch-1 6y agoIt's a joke man, why downvoting? :)
- citrea 6y ago"What I've learned in 45 Years in the Software Industry" - a 1000 Word article. (:D)
- uppsalax 6y agoI loved the article! Thank you for sharing it. Even if I am moving my first steps into the industry (I'm a simple trainee at a Tech-StartUp and MSc student) I've already experienced many times the first point. I think trying to keep your feet (and mind) on the ground, even when you have a huge expertise is fundamental in communication, teamwork and goals' chasing. For example a friend of mine, graduated in one of the top programs in europe at Rotterdham Business School, has a huge expertise in the R language, he is able to manage data promptly at work, efficiently delivering in 2 hours what his colleagues do on Excel in the whole day. However he has big problems in communication here in Italy, he is not able to understand what other people with different background/expertise are asking to him precisely and this is becoming a huge issue in terms of career development.
- trentnix 6y ago3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand code that is straightforward to maintain.
- castlecrasher2 6y ago>Assume the next person to maintain your code won’t be as smart as you. It's especially easy to assume this because I've often gone back to code I made a year or even months ago and barely understand it.
- deleted 6y ago[deleted]
- jjice 6y agoAt a previous job, I was the only person to document architecture structure and design choices in a document in each repo I worked on. They turned out to be very helpful for the new employees we took on over my time there. While that's a great plus, the real reason I wrote those was for myself because there is no way in hell I'll remember how to deploy this app to a new EB instance.
- trentnix 6y agoThat describes my motivation for writing documentation perfectly. In my last job, I wrote documentation so I could quickly get back into the context of the different problems I was working on. Context switching was a real challenge in that environment and I referred to my own documentation frequently. And sometimes, writing documentation helped me better understand the problem I was working similar to the idea that teaching a topic is a great way to learn.
- koonsolo 6y ago
- davidhyde 6y ago> “ When you know something it is almost impossible to imagine what it is like not to know that thing. This is the curse of knowledge, and it is the root of countless misunderstandings and inefficiencies.” A few months ago I came across an interesting actively developed project in embedded rust which was very technical. Full of acronyms and concepts that I was not familiar with. It took quite some time to get up to speed with how it all worked and so I took the time to add / expand README.md files for each example, explaining what the acronyms meant and the general gist of each example. It was a worthwhile exercise for myself and I figured that it was worth sharing the perspective of a beginner too. My benign pull request remains ignored and unmerged and it makes me feel like a bit of an imposter. I thought nothing of it at the time but now I wonder if this is classic case of “the curse of knowledge”. Perhaps the author just can’t see the value of it.
- noisy_boy 6y agoI think they are doing themselves a disservice by ignoring something that elevates overall understanding, ease of onboarding/troubleshooting and generally, the polish, of the project. I love documentation and usually manage to set aside time to add details in the README/wiki etc. It is a great way to share details with others and myself, six months down the line, because I don't have a super sharp memory.
- davidhyde 6y agoThis is true but the “curse of knowledge” from the article explains why this can happen. It is easy for outsiders like you and me to see the value of such things but as an insider you can become blinded by your knowledge.
- noisy_boy 6y agoThat is possible. Though I equally like documenting things where I can be considered an "insider" that I know only other "insiders" will see. I think that it is about being able to see the usefulness, and beauty, of a well made documentation irrespective of the level of familiarity/proximity. Either you see value in it or you don't.
- zerop 6y agoIt was good to read this... But today most of the big/famous companies (except Tier 1s) aren't giving importance to these. Infect in one of JDs of a big company for Engineering manager role I saw "Ability to negotiate" as a requirement skill for that job. I would blame the fast-fail culture brought up recently.
- tannhaeuser 6y agoWhat I'd be really interested in is how tech churn is perceived by people older than me. I'm only 30 years in, so I tend to defend my generation's choices such as POSIX, SQL, XML, SOA, Java, and C/C++ before that (plus special-purpose pet peeves of mine such as markup/SGML and logic programming which came before) though I'm also claiming to be proficient in and generally open towards new tech. I consider most of supposedly new tech as rehashes of things past rather than real progress, and to be just lock-in schemes and sucking in another way compared to the tech that it is supposed to replace. But I'm really uncertain if I'm just falling victim to generational effects, like, say, the proverbial COBOL programmer being ridiculed by younger devs to instinctively grow their own tech career. Still, for me, there's a moment around 2006-2012 when the industry went all-in on "the Cloud" and consumerisation of IT, when before I saw canon, progress, and consensus through standardization. I guess this is something that can't be objectively measured; but I can say that initiatives for standardization have almost dropped to zero compared to the 1990s and 2000s.
- scsilver 6y agoAs a young blood, 5 years in, got hired by learning react in the great JS hiring of the mid 2010s, I look back towards those standards bodies as something that would be very beneficial now. All we have is chrome creating standards by monopoly. Maybe I have a older mindset aswell. My training in in Civil Engineering and I have my expectations for standards bodies set pretty high because of it. The code is so high level now, going through algo and data structures I see the benefit of that fundamental knowledge, but also see that you can be a very valuable engineer to a company without it(thanks to the rich developer ecosystem for that) If we think about the maturity of software like a biological ecosystem, maybe the zen garden built by past engineers has overgrown into a dense and varietal forrest. Im not sure if its bad or good, maybe there are more niches to move into.
- breck 6y agoI'm only 15 years in but have thought about this a lot. I agree with you that there is nothing new under the sun; that we just cycle back through old ideas; fashions come and go and come back. However, the environment changes so often old ideas go from being "possible" to "they just work" or "possible but really slow" to "instant". These environmental changes can make orders of magnitude differences, and cause old ideas to suddenly feel very different in practice. When I think of programming languages for example, of the languages you mention, a lot of their design (like matched brackets in XML), were decisions that made a lot of sense when we had monochrome editors, but now with extremely fast and advanced IDEs, we can take old PL ideas from the 50's and design languages with IDEs in mind that are a lot less cryptic and concise.
- coffee 6y ago> At EDS, the culture wasn’t like this. People moved in and out of management roles. There was no stigma associated with moving from roles with greater scope, like strategic planner, to roles with more narrow scope, like PM or project-level developer. This sounds amazing. I'm curious...how does salary change? Or does it change? How is all of this handled...
- bcheung 6y agoThis is really good advice. Myself personally, I have been programming for decades as well and struggle with the curse of knowledge. Curious what other people do and what struggles they have had. Having spent time studying Category Theory I see a lot of value to using it in my code but it is not common knowledge and often confuses others when you start throwing around terms like functor, monoid, monad, etc. At the same time I don't want to write code that isn't as reusable or to that isn't as maintainable. Are we as an industry limiting our own potential by deliberately not using knowledge when it is beneficial for the sake of greater communication? My personal philosophy when working with teams is to exclude some of that stuff but slowly introduce it and train junior developers on some of the concepts in the hope that I can push that knowledge forward. Curious what others think of this dilemma and how they address it.
- jbaudanza 6y agoI also struggle with this issue, but I've never heard the term "the curse of knowledge." I'm happy I have a name for it now. When you try to explain to people that it's difficult to understand that other people don't know something that you know, you sound a little crazy.
- datenwolf 6y agoWith respect to > 1. Beware of the Curse of Knowledge I'd like to add, that knowledge can lead to "knowledge paralysis": The more knowledge and experience you have on a certain topic, the more problems and caveats you'll spot right away. Awarenes of those may prevent you from actually engaging in productive activity and instead tiptoeing around the problem at hand, instead of just implementing a "straightforward" solution (that ignores the 0.1% of corner cases, you know about, but won't have to care about). This is omething I'm struggling more and more these days.
- rodolphoarruda 6y ago7. Dress Code It has changed a lot. From suit and tie to whatever you feel like wearing.
- Ericson2314 6y agoMost of this is perfectly archetypical "hindsight says it's all about the little things", exactly what we expect our elders to say. But consider no 100 year old dying in 1950 would bother impart: > At the end of the day, sweaping the barn really is how all my children made it to age 5 > A rust-free butterchurn keeps those fingers attached, don't rest though there's a wall of glass Good Timeless advice is a function of stagnation. > Fighting complexity is a never-ending cause. > Beware of Lock-In These ones, though, I like. We should strive to understand problems in full generality, which may increase simplicity. But our current cloud-and-Docker-snakeoil trend is either epicycles, not ellipses, or lock-in, never neither.
- qwantim1 6y agoGreat advice! A correction: Ruby the language is not really a lock-in problem. It’s specifically DSLs, and the concept is non-Ruby specific. People that got bit by Chef (which is still great, but it can get unwieldy) may blame Ruby, but the problem there was things getting much too far away from the actual CLI commands, so it was a DSL lock-in problem. The warning against DSL lock-in may be founded. But, when it’s kept simple, DSL lock-in may not be there as much. If you can quickly translate it to something else, you’re good.
- fjdjsmsm 6y agoWhy do all of the posts about the coup keep getting removed?
- simon_mannes 6y ago> Teams move at the speed of trust. I'm only 7 years into my professional software engineering career and this really stuck with me. Over the last two years I had the honor to work with an awesome team on an interesting project, and yes, trust is the basis of exceptional teamwork.
- barnacled 6y agoSome cynical lessons from 15 years in: 1. Politics is everything - how you are perceived is politics, whether you get assigned the projects you want is politics, career progression whether technical or managerial is entirely politics. You will be told various nonsenses about 'flat structures' and 'meritocracy' throughout your career but it's bollocks. Play the game badly and the flat structure is your career. 2. Most programmers don't care - as much as you might care about software engineering principles or even minimal levels of quality in your work, you will be shocked at the degree to which most of your colleagues do not. They might give lip service to it but when it comes to it most justify doing a crappy job by hand waving about being practical. If you talk even mildly about code quality expect to have it patronisingly explained to you 100 times over that you are a perfectionist and customers don't care and etc. Etc. (Of course these arguments are easily rebutted straw men but good luck getting that across). 3. Raising what's right usually hurts you - people do not like to hear uncomfortable or irritating truths. See point 1. Pointing out that something is a risk or severely broken is more likely to get you hassle and lower people's view of you and God help you if you are proven right - there is never a 'oh you were right!'. Nobody likes to be made to look bad. Again see 1. 4. Never underestimate how shit the code is in your next job - the interview very rarely gives you the slightest insight into the quality of a new employer's codebase and never be surprised at just how terrible it can be. 5. We'll fix it later means we will never fix it - technical debt is a lot like national debt - ever growing and rarely paid down. If you are fobbed off with a 'we will refactor that later' comment take that to mean 'this is shit and I am fine with that'. 6. Sideways shifts reset your career to zero - there is no such thing as treating development experience as fungable. You are only as good as your years in this particular slice of the industry and more often than not you are only as good as your years in this particular company. 7. Fuck you pay me - at any time if you are told by an employer that you are part of a family or that your pay rise couldn't happen because you are already paid highly for your title or other such nonsense, start looking for another job, you are being used.
- bluefirebrand 6y ago> 6. Sideways shifts reset your career to zero - there is no such thing as treating development experience as fungable. You are only as good as your years in this particular slice of the industry and more often than not you are only as good as your years in this particular company. This one has burned me a bunch of times in my career already and I'm not quite a decade in. I really want to find a corner of the industry I can focus on and gain momentum in my career but it's been challenging to do that.
- ncmncm 6y agoAll good advice. But all too often, the very best possible advice is, "Get out. Get out now!" Get to a place where the Good Advice quoted above works. It can be very hard to tell that, up front. You have to try and see, and plan to skip along if you guessed wrong. Most of my regrets, over 45 years in engineering, are over sticking around when what I had to offer was not what was welcome. Sometimes, what they needed, I didn't have. Other times, they didn't know what they needed, didn't want to know, and didn't recognize it under their noses. Either way, you would much better be elsewhere sooner than later. For the young, it is tempting to try to prove your bosses wrong. That never, ever works. First, sometimes they aren't. When they are, they will be committed to not seeing it. It is always overwhelmingly better to deliver solutions to people eager to get them. So, find those people. Often, you will have to prove yourself and the value of your ideas. That is not a reason to scram. But make sure before you start that success has a definition. "Ten times faster", "ten times cheaper", "ten times fewer server instances", "ten times less latency", "ten times less downtime" are hard to mistake, are remarkably often achievable, and are sometimes welcome. In some cases, "two times" stands out; I recently got Quicksort to go twice as fast, and that drew some notice.
- zmmmmm 6y ago> Clean, understandable, and navigable code and design It's interesting to see "navigable" in here - I've struggled to articulate in the past this problem and I think this nails it. We often see simplicity come at the cost of "navigability". All the configuration by convention frameworks have this problem particularly heavily. I'm often at a complete loss to trace the mechanics of what is happening in things like vue-cli, Rails / Grails, gradle, and many other dynamic frameworks. They achieve remarkable simplicity, yet I often end up hating them and swearing at them because I can't exercise my understanding of fundamentals to reason about them and rationalise what they are doing. "The database connection must be getting established somewhere - it should be traceable back from the point where the connection is used in some way" - well, no you may have to understand most of the entire underpinnings of the framework before you will achieve that understanding. I think this "navigability" idea really fills that gap well. Things should be simple, but they should always stay navigable based on fundamental knowledge.
- Arelius 6y agoI agree, and I like the concept of "navigability". But I'm not sure I agree that many of the listed frameworks like Rails, are simple in my experience. There is a lot of "magic" complexity, but they just go through efforts to hide that complexity from you. It appears simple on the surface, but on deeper dive the complexity is still there.
- ng12 6y agoWebpack is one of my absolute favorite tools. It's easy to reason about and a pleasure to use. It absolutely checks the "navigable" box in my book. However, it got constant flack (esp. here on HN) for being too complicated. Apparently asking a dev to spend a day learning the tool before getting started on a new project was too much to ask. Now the best practice is to use a meta-tool like vue-cli or react-scripts to abstract away Webpack, trading navigability for simplicity. Simplifying complex tasks requires magic and good luck debugging when your magic incantations don't work as expected. I totally agree that navigability is super important and I wish I knew how to better emphasize it in my projects over the "batteries included" approach that has the best marketing.
- chii 6y ago
- aj7 6y agoRegarding simplicity, I’ve observed the following about design. Usually, designs become more complex with time. If the RATE of complexity increase exceeds a certain level, the design is crap and that approach needs to be scrapped. Occasionally, a design gets simpler as one goes forward. THOSE are magic!
- diskmuncher 6y ago> Seek Consensus — Take the time to bring your whole team along. Let discussion and disagreement bring you to the best solution. There you have it! What the political leaders in this country have been failing to do.
- migueloller 6y agoI was pleasantly surprised by the list of "fundamentals". Here I was, expecting something rather specific about the discipline. And I'm so happy whatever I was expecting wasn't what was there. The qualities described do seem like true "fundamentals". It's a human effort after all.
- SoSoRoCoCo 6y ago"Beware of Lock-In" 45 years ago when there were, oh, 5 computer languages: YES. Today, with a dozen languages and hundreds of frameworks and tens of thousands of packages in those frameworks, maybe not so much. We could do with a little "lock in" for maybe a few years. IMHO.
- known 6y agoIMO we have to constantly learn and unlearn in software industry.
- YeGoblynQueenne 6y ago>> When you know something it is almost impossible to imagine what it is like not to know that thing. This is the curse of knowledge, and it is the root of countless misunderstandings and inefficiencies. Smart people who are comfortable with complexity can be especially prone to it! The more I learn about smart people, the more I realise how dumb they are.
- dangisgay 6y agoThis is kind of why skills are fucking pointless. Why get good at a skill when people don't care about skills. I'm so happy this country is falling part. I hope we all die very soon
- offtop5 6y ago6. Is by far the best career advice. Instead of fighting and arguing all day, and getting fired anyway you can often just walk away from the situation. In fact I would say that's the only real conflict resolution that ever works.( In and outside of work ) Family not treating you right, don't complain about it on Reddit. A friend of mine ended up staying in a homeless shelter for a short while at 19 since he didn't like how his family was treating him. And he ended up with a great career after that.