28 ms·

Ask HN: What topics/subjects are worth learning for a new software engineer?

253 points by jmeiha 8y ago

I'm trying to cultivate my ability to identify worthwhile topics to invest time in learning since I have only recently graduated from university, so for the most part have been sticking to the yellow brick road laid out for me thus far. What would some of you guys think about learning if you were just starting out in the industry? Or even better, what does your process for orienting yourself and making these kind of decisions look like? Any and all advice would be greatly appreciated.

codingdave 8y ago
Like many questions, it would be easier to answer if we knew what your goals were. Do you want to grow into being the lead software person in a small company? Found your own place? Be a contributor in a large space? Work in academia? Teach? Be a digital nomad? Do design-driven web work? There are hundreds of choices of where you can end up. And they all result in different answers. So if you'll pardon a cliched question -- where do you want to be in 5 years? What would that person know? The answer to that question is what you should be studying.
- jmeiha 8y ago
  Interesting - you've pretty much hit the crux of my issue. I'm pretty aimless right now, which is a big part of why I struggle to make choices on things like this. Setting definite goals is something I've always kinda danced around, it would be good to build up a habit of doing so going forward. Thanks for the words of advice, definitely has me thinking.
  - theresarapior 8y ago
    Your journey will evolve over time, too. But to get started, just get stuck in building some web app that helps you or is funny to you, and throw it on heroku as a project. Put everything on github and begin growing your coding resume that way. A software engineer friend was telling me last night why it's so hard and exhausting to learn. It's because you use so much thinking power learning something new, but the more you do it, the more it's muscle memory, like driving a car. Maybe 80% of the time you spend learning will actually be tiring and boring and hard. So, it's probably going to be painful at first, but having the drive to complete projects and get stuck in will get you where you want to be (even if you can't decide where that is, yet :) ) One warning would be to stay away from just learning languages. Logic and syntax are important for sure but knowing all the tools needed to build one piece of software is where you gain useful skills.
hirundo 8y ago
Regular expressions: https://www.xkcd.com/208/ https://www.xkcd.com/208/ Also, study your debugger until you grok every feature and command, and then keep studying it until it's firmly embedded in your muscle memory.
agitator 8y ago
If you are working at a new job, ask questions, ask lots of questions. The more you put your ego aside, and focus on absorbing everything like a sponge, you will leap ahead of your peers and your early career will set you up for long term success. Often times, imposter syndrome will keep people from asking questions out of fear of being judged as incompetent. Let me tell you, the people who immediately ask about what they don't know are the ones you want around, the ones who pretend to know, or struggle through issues, or end up with odd solutions that need to be reworked take up more time and cost teams more money. The more you seek to understand form other more seasoned engineers, your peers, etc will only benefit you and will also have the added effect of building relationships and respect from others that will also set you up for a better long term career.
leetrout 8y ago
I invest in my tools and learn a bit more than what I need to make them functional. This isn't always a tech deep dive- sometimes it's just being a "power user" and knowing the shortcuts. I haven't met a recent grad in the workforce that uses git to its potential. They cargo cult workflows which is a good start but get in to trouble by not understanding just a bit more about how you can make temp branches / rags to keep from destroying commits in a rebase or how to prune duplicate commits from a sloppy rebase. For terminals - using tmux or screen and understanding how they work enough to pair up on a remote box. For any language knowing how to debug and how to profile. Understanding that print/println/log debugging is great and just keeping moving when figuring out why something isn't quite right. This isn't a hard answer to what you asked but it's what popped up in my mind.
- majewsky 8y ago
  > I invest in my tools and learn a bit more than what I need to make them functional. This isn't always a tech deep dive- sometimes it's just being a "power user" and knowing the shortcuts. If you (the asker) are using a Unix environment, I would recommend that you set up a weekly appointment, maybe every Friday, where you sit down and read a random manpage. Not for the sake of memorizing everything, but to learn what your tools can already do if you just remember to look up the right invocation when you need it.
  - hyperpape 8y ago
    I like the idea, but I don't think a random man page is the best approach. The signal to noise ratio is quite low. Maybe look at something like Julia Evans' bite sized linux.
    - marmot777 8y ago
      Why does it have to be random at all? Why not start at the beginning of a Linux book and something like http://wiki.bash-hackers.org http://wiki.bash-hackers.org? Even acting systematically leaves room for astonishing synchronicities.
- 8y ago
mattlondon 8y ago
I'd recommend to learn several languages that are pretty different from each other. E.g. java, golang and javascript. Learn enough to be proficient in each - enough so you are fully comfortable in the ecosystem and could happily start a new project from scratch and do it all in that language + ecosystem without much help or stumbling blocks. Benefits: learning multiple languages makes you better in each by opening your mind to new approaches or reinforcing higer-level understanding... Plus you won't become wedded to a specific language or "scared" of touching something new you've not done before. You'll see more similarities than differences, and although you may never actually get to code in java/golang/javascript professionally the experience of learning and coding in the different languages is really powerful in my experience. Other than that, I am personally a fan of "full stack" development. Learn a little bit about everything so you can hit the ground running on whatever project you land on - web development, databases, mobile device, backend developer, continuous integration, containers, serverles etc etc. Play around with all of these and you'll learn a lot about designing systems and what really matters. Again - you'll see many similarities across all of these apparently different areas of expertise, all of which will be to your benefit. With respect, ignore comments about learning the tools - tools change rapidly and you might not get to use your particular favourite tool/ide/editor/source control system/operating system/hardware on your next proejct, so just make sure you stay flexible. Good luck - you're in for a really fun ride.
baron816 8y ago
Too many software engineers get into a mindset of “just make it work.” For me, making it work is only half the battle. You need to build something that will make it possible for you or someone else to come back to later and be able to reason about and modify or extend. I interview a lot of job candidates and I give them a very simple problem. Pretty much everyone can solve it, but I’m not just looking for them to solve it. I’m looking for them to find the right abstraction—one that will make it easy to extend the problem and for junior devs to look at the solution function and understand exactly what it’s doing. Almost no one passes. My coworkers ask “just make it work” problems in interviews, and I believe that has contributed to our codebase being a nightmare to work with. I think most software engineering is an organization problem, rather than a optimization problem. My advice: learn functional programming and object oriented design. You will learn how to write declarative code that is loosely coupled and not dependent on its context.
- ganashaw 8y ago
  Would you mind sharing that problem? Always looking to improve my own interview questions.
  - baron816 8y ago
    The question is to make a function that will group the values of a linked list by odds and then evens. So 1->2->3->4->5->6 becomes 1->3->5->2->4->6. The solution essentially comes down to creating filter and concat methods for the LL, so you get something like: function groupByOddEven(ll) { var odds = ll.filter(isOdd); var evens = ll.filter(isEven); return odds.concat(evens) } If anyone were to ever get this far on their own and implement the LinkedList class correctly, I would have them make it so that they could make a higher order function that would receive any predicate function and then group by those values first, then its complement.
    - jtchang 8y ago
      My first thought is below. However I'm not sure if this is a good problem to ask unless you want them to iterate on the solution and you mention you want to do in a functional way. def groupByOddThenEvens(someList): odds = [] evens = [] for x in someList: print x if x % 2 == 0: # Even evens.append(x) else: odds.append(x) odds.extend(evens) return odds
PopeDotNinja 8y ago
Learn to pay attention to that feeling that tells you an abstraction is missing. When you try to bring something to life using the tools you know & it starts to feel much harder than it should be, that's a good sign there might be another tool out there you can use to get the job done. If you can't find anything, that's a good time to start asking if it makes sense to try a different approach or build your own.
te_chris 8y ago
Learning to understand the domain you're modelling thoroughly. To ask enough questions so you don't build the wrong thing for the person who's requesting the work.
Insanity 8y ago
A few things that come to mind: 1) version control (git at least) 2) soft skills (how to deal with people) 3) learn some new languages outside of your comfort zone. Learning new languages is always useful and you can get a feel of different domains 4) The tools you use to make your magic happen. Learn your IDE shortcuts, optimize your toolchain. 5) And, kind of related, think about your ergonomics. Working at a computer for 8 hours a day can be quite bad for your health. Make sure your environment is good for you, desk at the right height, good mouse / keyboard, and maybe do some sports on the side.
- stevewilhelm 8y ago
  I would add learn how to do Test-driven Development
skrebbel 8y ago
Learn to ship. Make something useful, even if just for you and maybe three friends. Ship that. Sooner. Ship it when it hardly works. Then iterate. This will teach you all the good bits of "agile", some requirements thinking, pragmatic programming, and (if it's a web thing) some basic "how to maintain an app on a server" skills, all in 1 go. It's also all stuff that is super hard to learn from books or from too-experienced coworkers.
- garysieling 8y ago
  I found that blogging the steps as I do side projects made progress really helped with this - it makes it feel like I'm always completing something. It also allowed me to break a problem down into small steps (what be done in 30 minutes-1 hour before work).
yashap 8y ago
Take on challenging problems, ask lots of questions. Always try to understand both the technical decisions and business decisions/value in whatever project you’re a part of. Try to avoid anything resembling blog/resume driven development - the real things to worry about are writing code that solves the business problem in a simple, quick way, while being easy to modify in the future, low on bugs, easy to monitor, and ideally reasonably performant. Using hot new frameworks/tech is unimportant, but writing well tested, modular code with the right data models, simple architecture, and good logging/telemetry/alerts is very important. Get comfortable with a set of tools that make sense for the work you’re doing - an editor/IDE, a debugger, a shell (and common Unix programs, if you’re in a Unix environment), a VCS, whatever build/deploy tooling your company uses, etc. Avoid the common dev mindset that dev managers, product managers and/or designers are the enemy. It IS your role to focus on important technical needs, but realize that they must be balanced against delivery times and business value. Sometimes you need to leave hacks in place, if there’s not too much cost to leaving them there. New features and bug fixes ARE often more important than cleaning up code/architecture, when you do take time for technical priorities, make sure you’re choosing high impact ones.
- Aeolun 8y ago
  I think you are needlessly dismissing resume driven development. While I agree that it is no good from a technical perspective, it’s really a fairly big part of what companies look at when they hire you (as I learned). Make sure it contains at least the latest fancy technologies in a professional context, and it will really help with your desirability. Then after you join the company, you can try improving their code to be up to standards.
  - yashap 8y ago
    We might have a different definition of resume driven development. Choosing a company that uses a tech stack you think will be good for your career is fine, though it wouldn’t personally be one of my top criteria. But what I’m advising against is choosing frameworks, architectures, databases, etc. for a specific project, simply because they’re the hot new thing, vs. actually being the best choice for the problem you’re trying to solve, at the company where you’re solving it. Also, I personally don’t think the specific stacks you’ve had experience with play much of a role in getting top dev jobs. Getting great referals from senior people is generally the best way to get top dev jobs IMO, and you get these referrals by shipping reliable, high quality software consistently, and being pragmatic/mature.
amriksohata 8y ago
Hammer the people who should be coming up with requirements, the BA or PO or whoever it is to take responsibility for proper requirements. From your end read things like the Clean Code book and Head first design patterns.
VargasTheOld 8y ago
The basics, the stuff that is one or two levels of abstraction below the 'normal' stuff. Write a compiler, write a query optimizer for an open source SQL database, write a new IO subsystem or memory allocation subsystem for MINIX, write a kernel for a Vector PU in, say, CUDA. Write a 4k demo in assembly. Grab a soldering iron and built your own mouse then write a driver for it. Write your own TCP/IP stack. When I was a student, way too many years ago, the Uni I attended was very heavy on theory, lots of discrete math, physics, calculus, Big O analysis, electronics and computers architecture, Lisp, Prolog, CLISP, data structures and algorithms, wide search vs deep search, rebalancing red black trees on paper, etc. At the time I was very unhappy about it, I thought "why are they not teaching us C++, Visual Basic and this new language called Java that it's clearly the future?" But now, twenty years later I am very happy with the formal education I got. Having an understanding and an intuition of how things work all the way up and down the stack from transistors all the way up has proven invaluable during my professional career.
traviscj 8y ago
For the love of god, learn how database indices work -- basically everything at https://use-the-index-luke.com/ https://use-the-index-luke.com/
_Marak_ 8y ago
Learn about the concepts of Continuous Integration and Continuous Deployment. Learn about implementing code coverage into your projects so you can track the percentage of code paths which are actually being covered by the tests. Once you have the mindset of actually testing your software and tracking the code coverage your entire approach to development will change and improve.
Peteris 8y ago
I'm going to take a very different stance here from others. First, you should ask yourself - what kind of engineer do you want to be. Why are you building? Then, read about the people who became the best and their early days. What did they do when they were in your position? Did they study a set of topics or did they pursue their passions? Taking and highly-weighing advice from people not at the top of the field could be very detrimental to your development as an engineer. From reading books like: Coders at work, Masters of Doom, Making of Karateka, you will realize that the best engineers were driven by their ideas and projects very early on. They ended up learning to make things happen. But don't take my word for it, find these people, study their stories and pick the path you would enjoy the most. This approach will not just make you a strong career engineer, but could turn you into one of the greats - the people that get to push the field forward.
scarface74 8y ago
I know this is going against the grain for HN, but I’m going to suggest not learning the latest leetcode, computer science algorithms. Most places in corporate America are doing cookie cutter problems that have been solved before in different domains. Unless your company is operating at FAANG or even Twitter scale, all of the cross cutting, infrastructure concerns have been solved and you can use an existing piece of software to solve it and it’s usually open source. What I do suggest you learn that most people don’t know is going deeper down the stack, domain driven design, continuous integration/continuous deployment, at least one public cloud environment (Azure/AWS/GCP).
captn3m0 8y ago
1. Learn to Ship 2. Read everything on this list: https://blog.codinghorror.com/recommended-reading-for-developers/ https://blog.codinghorror.com/recommended-reading-for-develo... 3. Learn to go down the stack. The best engineers I've worked with know their stack deep. I wrote a blog post on this once (targeted at recent graduates, should be helpful): https://captnemo.in/blog/2015/10/12/get-better-at-software-development/ https://captnemo.in/blog/2015/10/12/get-better-at-software-d.... The list on the blog post is: 1. Join a community. 2. Contribute to Open Source projects 3. Write all code publicly 4. Do tech talks 5. Stay Updated 6. Learn more languages 7. Concepts Matter 8. Ship Products 9. Have side projects 10. Read technical books
- __exit__ 8y ago
  Knowing a stack deep is rather difficult when one attempts to also learn and keep up-to-date with the newest technologies. Or were you referring more to system/protocol stacks instead of programming languages/frameworks?
  - captn3m0 8y ago
    system/protocol stacks. Your ability to debug things faster and more accurately improves drastically if you can guess/know what is happen on the abstraction layers below you.
GijsjanB 8y ago
You need to narrow it down a bit. Know yourself. Find your passion. I know this sounds tacky, but there are sooo many variables in choosing a professional direction. You are the only constant. For example, it is very important to determine what kind of developer you are: quick n dirty, loads of languages, throw out some PoCs and go on or... keep building till it's perfect, 100% coverage, solid docs, etc. Than, what will you build? Embedded, games, web, medical, imaging, AI, infosec, etc? Answer both questions and your next step will be easier to define.
perlgeek 8y ago
There are lots of topics you could look into: * testing * logging * writing code that is easy to operate * deploying code * build systems * algorithms * API design * refactoring * security practices * development processes (scrum/kanban/whatever) * learning about the vertical / business domain you're in To be honest, I didn't plan too much ahead -- there were some topics that simply interested me (algorithms, security), and others I was thrown into because work made it necessary (build systems / deploying, logging). If you don't actively try to get into a niche, you'll get exposed to many of these topics, and likely many more that I forget. If you ever look back, and don't think you haven't learned anything new in the last 3 or 6 months or so, then you should actively look for opportunities to learn.
- scarface74 8y ago
  logging And for the love of all that is holy don’t just log to a text file. Use some type of structured logging framework (Serilog,StructLog,etc.) that gives you JSON structured logging that you can then query instead of depending on regular expressions.
  - majewsky 8y ago
    Why though? Even if your own app logs JSON, everything around it (the DB, the log collector, the metrics collector, the kernel, the LDAP server) most likely logs plain text, so you need to know regexes anyway.
    - scarface74 8y ago
      Oh that’s the other part. With the structured logging framework that I’m most familiar with - Serilog - if you send it to an output source like Mongo or ElasticSearch it logs documents. So you can query your logs. With Serilog you can tell it to always add certain attributes and you can tell it to add attributes with a certain context - like everything in a “using” block. As far as the logs that you don’t control, if they are in some sort of standardized format even if it is just a line of text, you can use logstash to create a structure around it. Of course with ElasticSearch, you have a powerful reporting app in Kibana. If you are on AWS you can send logs to CloudWatch and use the alerting, metric framework that’s built in.
carapace 8y ago
Learn Prolog.
antoniuschan99 8y ago
As long as you're working on projects you will gain knowledge in process and skill. Examples of these are Agile, Cloud, Dev Ops, Programming, Collaboration, etc. You also may want to specialize both in your skillset (Front End Back End) and Industry. Try to optimize by focusing on something you enjoy and are also good at.
stallmanifold 8y ago
Remember that software engineers have two skill sets: programming/development skills and domain knowledge. Many of the comments here are focusing on the former, but consider the latter as well. What kinds of problems do you like solving? What (business) domain(s) do you find interesting? Start thinking about that over the next few years and acquire knowledge of the business domain(s) as well as leveling up your technical chops.
theresarapior 8y ago
In short, choose a problem you have, then fix it the easiest way possible by building software/website/webapp/whatever. Language doesn't even matter.
auslegung 8y ago
I was recently given this list of books by some very skilled engineers who I trust 1. [The Pragmatic Programmer](https://pragprog.com https://pragprog.com) 2. Martin Fowler's [Refactoring Book](https://martinfowler.com/books/refactoring.html https://martinfowler.com/books/refactoring.html) 3. Kent Beck's [Test Driven Development: By Example](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530 https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...) 4. [Thinking in Systems: A Primer](https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557 https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp...) 5. [Zen Mind, Beginner's Mind: Informal Talks on Zen Meditation and Practice](https://www.amazon.com/Zen-Mind-Beginners-Informal-Meditation/dp/1590308492 https://www.amazon.com/Zen-Mind-Beginners-Informal-Meditatio...) 6. [Pragmatic Thinking and Learning: Refactor Your Wetware](https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor.../dp/1934356050 https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor....)
analog31 8y ago
Don't get too busy. This is easier said than done. I've noticed that when we hire newly graduated engineers, we saturate them with CAD (or its equivalent in programming), bureaucracy, and troubleshooting. They forget the cool stuff that they learned in college, such as math and theory, and burn out. If you want to keep up with that stuff, you have to figure out how to weave it into your regular work, so you have an excuse to continue learning more about it, or give yourself some free time to learn cool things that you might use later, or might not. A lot of people tend to measure themselves by how busy they are. I believe that's a death trap.
icc97 8y ago
My personal opinion but this is purely because I enjoy it the most is functional programming. So much of the positive changes I've seen of late come through functional programming. For example: * ReasonML - this is what the founder of React is working on now. The ReasonML claims itself to be JavaScript 2030 (I see it as JavaScript + TypeScript + Immutable.JS + Redux). This contains a lot of the concepts from JavaScript so is a reasonable step to make * If ReasonML isn't too scary it leads you down a path to OCaml, F# and Elm * Rust (not strictly a functional programming language, but is ridiculously fast and contains well implemented Linear Types that makes Haskell's Simon Peyton-Jones jealous [0]) - this is one of the most loved programming languages according to the Stack Overflow survey [0]: https://www.youtube.com/watch?v=t0mhvd3-60Y https://www.youtube.com/watch?v=t0mhvd3-60Y
marichards 8y ago
When all you need to do breach someone's privacy and often the law is publish: <a href="https://www.facebook.com">Facebook</a> then you need to learn about security and privacy and how to defend your users against the failings endemic in the web.
pulkitsh1234 8y ago
On a related note (sorry for hijacking) Should you invest time in learning for interviews or your own personal growth once you are 2-3 years in the industry ? I understand that both sets are not mutually exclusive, but where should you put your time on ? Investing time specifically to give interviews: Leetcode, Cracking the Coding Interview, TopCoder, etc., may increase the chances of getting a better job then your current one (and will make you a better programmer too). On the other hand reading books like 'the pragmatic programmer' and other classics, won't necessarily put you in a better position to get a better job (in most companies), but will surely make you perform better in the current one. So, is it ok to put it this way: * If you are happy with your job and you can see that you can stay 5+ years at the company (basically FAANG ?): Invest time in learning for personal growth (Design Patterns, Refactoring, etc) * If you plan to switch / want a better salary / company sucks / <every_other_reason> : Invest time towards preparing for interviews specifically ?
- amrx431 8y ago
  This is the most apt and serious comment in the thread.
- avocadoLife 8y ago
  This is exactly my dilemma. I've been in the industry for 2 years but done very little personal development in my own time and my job has been quite limiting in pushing my skills in the direction that I desire. I value my after work hours to pursue other things/exercise/have a life. This makes me put even more thinking into how should I be spending my already limited time. Currently I'm sticking to doing some MOOCs related to my my development path (Android) and then I want to crack on a few personal projects. On the other hand, the clock is ticking and I really would love to prepare well for better career opportunities...
akudha 8y ago
One non-tech answer is learning to listen and learning to ask intelligent questions. Assuming you are writing software for people to use, these skills can be very valuable talking to users, executives and pretty much anyone a software engineer deals with. Maybe this is not too useful if you are working on some non user facing stuff like hard algorithms or protocols, I don't know. I've seen even experienced people end up asking leading questions and get the answers that they want (or think are right), instead of just letting the other person tell them what their thoughts. The result is weeks or months of wasted effort, bugs and user unhappiness.
jrvarela56 8y ago
Product Development/Management. Understanding the ‘inputs’ to your role will make you more effective. Learning the WHY you’re building helps you prioritize and gives you credibility when arguing for/against decisions at a team level. Learning about what a PM does has helped me make sense of how my work as a SEng relates to management, product and design. Specifically, the way I now spec, test and design systems in order to facilitate legibility, QA and coherence with the domain of the product has been greatly influenced by my amateur knowledge of product dev/mgmt.
vogre 8y ago
Learn SQL and you will be able to work with any data-related app. Learn HTML and you will be able to make an UI out of nowhere. Learn GIT and you will be able to share your work with others. Learn unix shell so you can deploy all that shit and conquer the world.
- garysieling 8y ago
  SQL is incredibly valuable, it also allows you to do a lot of analysis to triage tickets or to get business insights (how many users does this feature affect, etc)
- chubot 8y ago
  Yes it feels like SQL, HTML, and shell are ubiquitous and powerful technologies that most people think they know, but probably don't. Certainly I could have learned more about them in the first decade of my career. 15 years into it, this knowledge continue to pay dividends. I like this contrarian advice: rather than chasing the latest new thing, learn SQL, HTML, and shell. They continue to exist because they do things well that Java, Python, and Go don't. I suspect that will still be true in 10 years, so it's a good thing for new engineers to invest in. (Learning the foundations of git is good too, although the outer layers are arbitrary and nonsensical.)
danielrhodes 8y ago
Learn a language exceptionally well. One thing that makes younger engineers stand out is having mastery over a language. This will be evident to most interviewers and will be a big help in day-to-day tasks. It also opens the door to having a good mental model for becoming very proficient in other languages, which you will definitely need to be down the line. Getting good at various patterns that are native to the language, understanding how to profile/use debuggers, understanding memory and CPU performance, the ecosystem, memorizing the standard library, etc are all part of this learning.
honkycat 8y ago
"Only a fool thinks himself to be wise." Learn time management. People management. Fitness. Productivity science. Read how the other people succeed. A lot of very smart people take time to write excellent books on all of these topics. Why make the same mistakes they did? Learn to read books, and learn from the best. Adapt their lifestyles into your own.
davidwihl 8y ago
Learn about data, data science, statistics with a guise towards Machine Learning. Learning about data and statistics will give you a skill in numeracy that will be very distinguishing compared to the majority of developers (as evidenced by the other comments). This will help you quantify your accomplishments, ask thoughtful questions about the numbers others (including product managers) use to make decisions and give a fresh perspective to arguments that often lack credible facts. Taking this further, with more math, can lead to proficiency in Machine Learning, which I think is the most important change in computer science in the last ten years, and likely very important to all developers in the next ten. Background: started three companies (IPO, sale to a big tech company, crash'n'burn), CS degree from an Ivy, now working at Google.
jeena 8y ago
Learning how to deal with dependencies. Learning integration into a system. Learning basic DevOps. Learning versioning of your software.
michaelchisari 8y ago
Stress management and communication skills.
master_yoda_1 8y ago
Office politics :)
- XalvinX 8y ago
  this is huge for the typically introvert, nerdy, and socially awkward (and probably sexually frustrated...) computer guy. i lost more than one job because i didn't understand just how underhanded people can be in an office, and how there are webs of power and friendship between people that aren't always obvious, and as they say in Southern California, if you fight one bean you fight the whole burrito (sorry...but that isn't really meant to be racist)... best bet is to not get involved and keep your mouth shut, and avoid office romance, office gossip, office anything. it doesn't even matter how good you are, how smart you are, ...piss off one self-important middle manager who probably can't code something as simple as a++; and you are probably doomed. also, if you are male, be ready for a lot of homosexual advances. another awkward problem that can spin out of control very easily. you know what? i love programming, and i actually don't mind actually doing work....but most jobs are only partially about actually producing anything (this is getting more and more true all the time) and a lot more about kissing the right asses, enduring lots of worthless and unproductive meetings, and such. it blows, man.
tmaly 8y ago
I would focus on communication skills. Knowing what the end user wants is really important. For technical skills, I recommend reading Clean Code, Test Driven Development, and The Philosophy of Software Design.
- garysieling 8y ago
  Two thing sthat really helped me with communication skills were technical blogging, and volunteering with Big Brothers, Big Sisters - trying to see the world through the eyes of a teenager is really illuminating.
vinayms 8y ago
The most important thing to remember is that technology of all kinds, software frameworks and even programming languages themselves come and go, mostly affected by the whims and fancies of the megacorps that own them, or the communities that eventually implode into a thousand forks, whereas abstract design and techniques, aka algorithms and analysis, are forever (well, as long as we stick to the Turing machine model). It might seem boring and disenchanting for a recent graduate to know that the "dry and boring" stuff he just got done with will be recurring forever, but that's the way it is (if you are creative then nothing is dry and boring anyway). Even things like design patterns and best practices are basically product of the technologies and the general state of affairs that people had to wrestle with at different times, so they have a shelf life and must be reevaluated before application, without succumbing to cargo cult or taunts and ridicule. These things are after all opinions of few influential people propagated by their minions (jk), and not laws of nature as observed and analyzed for centuries by great minds. Its alright to have counter opinion as long as its not contrarian just for the sake of it. The second thing to keep in mind is that computer science/software engineering is basically like metallurgy - its purpose is to produce tools to make lives better, mostly for STEM people but also for laymen. So, while its perfectly alright to have some fun building sand castles in the foundry, it must be remembered that there is a greater purpose. An offshoot of this point is to pursue your interests in non "tech" field of your choice by getting away from computers every now and then; you never know from where you would get your ideas and where your ideas might have an application. As software guys we have an inherent freedom, much like artists, to explore other fields of knowledge, for it has benefits of many kinds. So avail it.
3pt14159 8y ago
Understand that questions that anyone reading HN can answer are largely filled with answers and votes that are what the average HN commenter thinks. The average HN commenter makes an average wage. Find people that sold businesses or make high six digit incomes and ask them. That said, my two cents[0] is that you should run towards the hard stuff, not away from it. Seems hard? Seems ill-defined? Top dollar. AI, Rust over C, Ember over JQuery, complex ETL jobs, OS programming, ASICs, FPGAs, space circuits, military gear, OS simulators, codebase analysis tools for red team, nano second computing for wall st, etc. My only proviso is that you should probably stay away from learning about cryptographic algorithms unless you're also interested in learning about quantum computing. Crypto right now is pretty easy and cheap for the 99.999% of entities that need it; and unless you're really good you're probably not going to break modern algos without quantum and even if you do there are a very small number of actors that will pay for your genius. MITM attacks that involve breaking crytpo algos are mostly state actors and huge criminal gangs. [0] I guess I've sold a company, but some people working at Google have made more than I did so I don't really feel like I fit the category of people you should be asking.
- 01100011 8y ago
  > military gear Maybe. I think there are lucrative opportunities in serving the military industrial complex but they are best exploited by insiders with experience and connections in that space. You need to know the lingo and need to know the right people. You also, probably, need clearance, which you can usually only get by being former military or formerly in the defense industry.
  - 3pt14159 8y ago
    I'm open to hearing perspectives if you have personal experience or friends with experience here, but that has not been what I've found to be true. My int / mil friends got in quite easily once they possessed the skills. They were all white, non-muslim, non-Russian and born in Canada or the US, but other than that even people with dual citizenships got S or TS clearance and worked on some crazy ass shit.
OliverJones 8y ago
I've been at this for a long time. I've had to learn many new languages, toolchains, and stacks over the years. I try to read at least one technical book a month. So will you. That's a fact. Understanding systems (no, not operating systems, not file systems, not that stuff) will give you the ability to create really good stuff. By "systems" I mean, basically, human systems. For example, understanding why the New York City subways are working poorly these days involves knowing something about politics, economics, electronics (the signaling systems) and demographics. Knowing why software companies sometimes have a hard time "putting themselves out of business" involves technical debt, new technology, resistance from people who know how to succed and want to keep doing it. Why doesn't the Roman Catholic Church let their clergy marry? That's the mother of all systems questions. How to bust into this way of thinking? Read "The Fifth Discipline" by Peter Senge. Be an anthropologist. To practice, read worseThanFailure.com as am amateur anthropologist. Don't just laugh, try to figure out WHY people do silly-seeming things.
- __exit__ 8y ago
  When you mention technical books, do you have in mind books on programming languages/frameworks or more focused on general concepts/skills useful for the daily work?
  - OliverJones 8y ago
    Both kinds of books. I subscribe to O'Reilly's Safari Books Online, and read whatever looks interesting.
BurningFrog 8y ago
The important skills in real life programming are about code maintenance. - Finding and fixing other people's bugs. Many people hate this, but you can learn huge amounts from this! After you've found the bug, understand why it happened, and learn from it. - Writing code that not only works - that's the minimal, given level - but is also maintainable and easy to change. By other people, even. Who you've never met, ideally. - Refactoring and testing are essential. If you're not spending at least 30% of you're time doing this, you're building trash.
mr_toad 8y ago
Which industry? There’s a lot of differences between, for example, embedded systems and database administration. Or HPC and mobile app development. Or even .NET and open source.
spiritcat 8y ago
all of teh subjects
snarfy 8y ago
In most other professions from doctors to electricians, years of experience equates to years of expertise. In software development, the technologies change so rapidly that a large amount of time is spent learning the technologies and tools. You may be a veteran Java or C++ developer with intricate knowledge of the underlying frameworks and implementations. At some point those technologies are replaced and that knowledge is worthless. All those years of experience are gone. Sure some general experience was gained, but anything related to specific implementation details is gone. The only thing that stays are the fundamentals. Focus on the core science and math aspects of software development, and your skills will only grow over the years, instead of constantly being deprecated as the landscape changes. Learn all of the design patterns and O notations and forget about the latest javascript framework flavor of the week.
- bor0 8y ago
  This is an excellent answer! With the ever-changing frameworks and libraries, I couldn't agree more. Rel: https://news.ycombinator.com/item?id=16352336 https://news.ycombinator.com/item?id=16352336
- mayankkaizen 8y ago
  What a valuable comment! I am 37 and I am not a programmer but I do read a lot about programming and related areas. Practically speaking, I don't see myself becoming a professional programmer but I still want to pursue programming just to whet my learning appetite. But what puts me off is this 'framework' dependent programming. It is just frustrating. Your knowledge of framework just doesn't stay with me. And I really don't learn anything fundamental.
corysama 8y ago
Ask old engineers about their problems and they’ll tell you it isn’t tech. It’s all people. Getting people to understand, get motivated, relax, get over themselves. These are the issues that hold back progress in practice. But, if you want tech, machine learning really is horribly interesting and useful right now. Ocaml and Erlang are good systems to learn from and carry over to other systems. CUDA is a rare and powerful skill. And, if you want to get serious, learn TLA+ or Coq.
whalesalad 8y ago
Things I look for when hiring: an understanding and appreciation for SOLID principles. Major bonus points for hexagonal architecture.
bra-ket 8y ago
business
rsyring 8y ago
My advice to aspiring developers can be found here: https://www.level12.io/blog/advice-to-aspiring-developers/ https://www.level12.io/blog/advice-to-aspiring-developers/ I believe it will probably give you some of what you are looking for as well as links out to other helpful resources.
_hardwaregeek 8y ago
Design. Tech can bloom and fade. Languages can be hyped and forgotten. But design stays. Learn to empathize with your users. Learn to design stuff that works well but also allows for fixing when it breaks. A good developer understands the interfaces and communication that is inherent within writing code.
jtolmar 8y ago
Completing projects does a lot to help you learn, and you can complete more small projects per amount of time than larger ones. So give your learning projects small, defined scopes. Actually properly learn the tools you find yourself using a lot. Like if you use javascript, don't be the guy who doesn't understand how "var" and "this" behave. And don't feel pressured to know everything - if you only use Python to edit scripts twice a year then it's fine to be looking stuff up every line. Try to ignore programming fads, though of course as a person embedded in society it's hard to know what's just hype. On average these things last as long as they've already existed, so learning things that have been around continuously for a long time is pretty safe. Since you're just starting, it's particularly important for you to learn things that'll last a long time, since you have longer to use them. Learn something that lets you make a website backed by an SQL database. It's a pretty safe bet you'll want to do things that fit this description a whole bunch of times. This is also a place where a bizarrely small amount of expertise can change "start asking for VC money" projects into weekend projects. You can go your whole career without ever needing to write a parser, unless you know how to write parsers, then you'll see cases where they're the best solution all the time. I don't actually know how much this is "if all you have a hammer everything looks like a nail" and how much is "boy I'm glad I know hammers exist." It's more niche, but I've never regretted learning more vector math.
di4na 8y ago
System Thinking and look at what Human Factors and Cognitive Systems Engineering does. It is always applicable and it will be useful in any role.
Annatar 8y ago
Operating system packaging: RPM, pkgsrc, ... You'll always come back to it as being your primary building and delivery block and it will provide huge benefits in terms of simplicity. You'll be running circles around everyone else in terms of delivery, simplicity and robustness. The learning curve is steep but well worth it, and it never stops paying dividends.
xer 8y ago
Read hacker news once every day and you will after a few years of reading be above the average software engineer.
GlennS 8y ago
You've got a lot of answers here, and quite a few of them overlap what I'd suggest. You're not going to be able to pursue them all. Personally, I tend to learn things that are relevant to my job as I'm doing it. Aside from technical things, that also means learning the domain you are working in if it's sufficiently interesting. For example, I worked in healthcare for a while, so I learned to read the HL7 protocol and the most important parts of the NHS data dictionary. Then I worked for an environmental charity, so I learned about thermodynamics and government policy making. If you learn the domain, then you will make more good decisions when you design your program. You will also be in a better position to be trusted to make those decisions yourself. For technical stuff, I like to spend more time and go deeper on things that I think are fundamental, things that I think will be useful in the future, and things that I have fun with. I don't like to spend time on things that I find yucky, that I intend to avoid using again, or that I think are based on unsound fundamentals. Sometimes I make wrong decisions in either direction. Either spending too much time learning something esoteric irrelevant in the long term, or spinning my wheels because I've skimmed over something without understanding it properly. I don't know a way to avoid this. A few specific things I think are good quick wins for a starting software engineer: * Version control. * Known what a dictionary/hashmap is for and how to use it. * Set logic (intersection, union, difference, xor), and how to do it in your favourite programming language. * Automation (bash or Powershell + make + SSH). * SQL + indexes (common in lots of computer programs, and SQLite fits nicely into the automation chain above). * Regex, how to use it in your text editor / IDE of choice, and how to use it on the command line. https://www.regular-expressions.info/
- GlennS 8y ago
  Oh, also, I forgot. Learn Excel properly: https://www.youtube.com/watch?v=0nbkaYsR94c https://www.youtube.com/watch?v=0nbkaYsR94c When you're properly automating things you'll want to use programs and command line tools instead, but you should still know Excel for the one-off quick and dirty data inspection. Also some of your colleagues will use it a lot, and won't have learned it properly. You can make yourself very useful.
pankajdoharey 8y ago
My favourite is Go-Jek reading list https://blog.gojekengineering.com/the-go-jek-reading-list-1088712ccc14 https://blog.gojekengineering.com/the-go-jek-reading-list-10...
Graham24 8y ago
Make sure you know about Orders of Complexity. Read the Mythical Man Month and other old books on theory.
XalvinX 8y ago
If you have a degree in Computer Science, that should be good enough. Every job is going to use different languages and platforms but for someone with 4+ years of the fundamentals under their belt, and probably at least 2 or 3 languages and 2 or 3 OSes from their various classes and all the programming assignments, learning new languages is pretty much a cakewalk. Any reasonable employer knows this. The problem (in my experience) was getting past the headhunters and HR departments and such..they often are staffed by imbiciles that know nothing about C.S. and you may have to do some bluffing here and there. The bottom line is that if you can actually get a BSCS you are a solid person and will have no problem with the much more trivial work in most software jobs...in fact, after your university courses, you will probably end up very bored very quickly doing rote, boring, repetitious work.
XalvinX 8y ago
some stunningly bad advice in this thread....if you followed all this shit you wouldn't even apply for a job until about 2030 or so...you have a fucking B.S. in Comp Sci, you have the skills and brainpower for any job out there. furthermore, you have no idea what the specifics will be for your job until you actually start... sure, go learn Prolog and XKPGL or whatever else, read the 40-some books on someones "must read list", (WTF even are "database indices"??? LMFAO...get real!!!!!!!! there are DBAs for that, and DBAs are a step or two below scientists or engineers...).... if you really want to, but 99% chance you are wasting your time. been there, done that, got the postcard, wasted a couple irretrievable years of my life. i squeeze out a big Pro-Log every morning, if you get my drift...most of this is just as flushable if you DO NOT KNOW YOU WILL NEED IT WITH CERTAINTY. 999 END
neves 8y ago
Very nice, but I still have to see a guide that doesn't just refurbish the ideas from the late Jerry Weinberg great book: https://leanpub.com/becomingatechnicalleader https://leanpub.com/becomingatechnicalleader

scarface74 8y ago

Is that really representative of the type of problem that your company is trying to solve? If not, why not actually create a simplified version of a real world problem your company solves on a daily basis, with a skeletal non working implementation, and corresponding failing unit tests and tell them to make the unit tests pass? That way you can actually see how proficient they are with the tools they use everyday. I had two job offers one time. One where the interviewer asked me how I solved real world problems and my experience and one where they wanted me to write a merge sort on the board. Guess which job I took? I’m not going to be writing a merge sort in real life and I don’t waste my time learning algorithms and studying leet code. I solve real world problems using existing frameworks from the front end to cloud and on prem infrastructure. Yes I have my geek credentials - started programming almost 35 years ago in 65C02 assembly, did bit twiddling in C for 12 years, etc. but I am way past wanting to reinvent the wheel.

TableOnTheRug 8y ago
Could you give an example of a simplified version of a real world problem?
- scarface74 8y ago
  The last time I was responsible for interviewing, the project I was working on dealt with a lot of data transformation - get data from various APIs and databases, transform it and store it somewhere else. This is all .Net and we were storing data in Mongo. So we were always working with lists of strongly typed objects. One simple problem was given a list of users objects, create a list of the target object and generate a userid from the first initial, first four of the last name. Then we had an algorithm for how to handle ID clashes. We had failing unit tests for all of the corner cases. We were hiring contractors and paying them well so we made one of the requirements that you had to know LINQ and EF. Even though we weren’t using EF that often, Linq is Linq and linq queries work the same with in memory lists, EF, and the C# Mongo driver. It was a requirement that they used Linq instead of foreach loops since Linq gets translated to Sql and MongoQuery instead of doing the processing in memory.
deleted 8y ago
[deleted]

Jemaclus 8y ago

Not the person you're replying to, but I'll share one of my favorites: Given an address such as "123 Main St, Boston, MA 00215", break it up into its component parts of: street number, street name, city, state, zip. (Note: I usually just ask for pseudocode, but if they want to write real code, they can.) The reason I like The Address Problem (TM) is that it's a real problem I've solved before. I've built address verification systems for some large US companies that you've almost certainly heard of. Most companies in the consumer space deal with some sort of address input, whether it's StitchFix deliveries or Redfin for real estate. Most of those companies outsource it, but still... you store customer addresses in your database, right? :) I also like it because the domain knowledge is already known for anyone who has spent any amount of time in the United States (where I reside). It's intuitively obvious to any American or even recent immigrant which part of the address is the street number, which part is the city, and which part is the zip code. You don't have to know anything special coming into it -- you don't need to know what a binary tree is or what a linked list is or any of the bajillion other CS concepts that I learned in college and see in interview questions and have yet to use in actual real-world use cases. All you need to know is how to read the front of an envelope or an entry on Yelp. Another reason I like it is that there are some really obvious ways to go, and there are some really complex ways to go. Arriving at a solution that _works_ isn't really the point. Any programmer out of boot camp can do that, and there are a billion complexities to addresses that most people don't think about. What's more interesting to me is how you arrive at your solution and is that solution something that you can build upon to handle various edge cases. For example, a lot of candidates will say "I'd use a regular expression," at which point I'll ask them to write one. They usually struggle a bit with it, but even if they do get it, I throw a curveball: "What if some inputs have no commas?" Then they have to modify their regex to handle comma and comma-less addresses. Some candidates will start off looking at the beginning of the string and saying something like "I'll look for a substring of Street/St or Avenue/Ave or similar", to which I can throw the curveball of "123 Main Street E, Boston, MA 00215" or a more fun one, "123 St Francis Ave, Boston, MA 00215" I really like the address question because of the endless curveballs I can throw at it. What happens if the user leaves off the ZIP code? What if they abbreviate the city to "SF" instead of "San Francisco"? What about apartment numbers? How do you handle pre-directions and post-directions? What's the city for "123 Main Street West Palm Beach FL 33409" and how do you know? What reasonable assumptions can you make about an address? For example, there are 50 states + a handful of territories, so states should _theoretically_ be easy to parse out... What other assumptions can we make about addresses? (Gotta be careful with this one -- people often assume that street names end in "Street" or "Avenue" or their abbreviations and forget about post-directions!) Since the domain knowledge is so simple even a 5th grader understands, the real challenge comes down to problem solving. There's no "trick" to it. You just work through the problem until you get stuck or we run out of time. Giving hints is fairly straightforward as well. At the end of this part of the interview, I often allow them to give me some thoughts on how they did. If they could do this whole 30 minutes over again, what would they do differently? Maybe not use regex? :) How do they think the US Postal Service handles addresses? Or Google? Again, there's no right or wrong answer for these. I'm more interested in whether they exhibit self-awareness, whether they can identify what went wrong earlier, and whether they can learn from their mistakes. (In case you were wondering, the _real_ answer I'm hoping for is "I'd ask Google Maps." I've had exactly two people give me this response in the 8+ years I've been giving this challenge. I don't know if it's because they think it's a dumb answer, if they know that I expect a code-related answer, or if it never occurs to them... but I like to think someone who wants to see what Google says isn't the type that constantly wants to reinvent the wheel. Note that NOT giving this answer is not a deal-breaker. I generally give the benefit of the doubt to candidates here.)

scarface74 8y ago
If one person came up with a complex algorithm and another person told me that this must be an issue that many companies face and there must be a service that specializes in this and the first thing they would do is to look for a third party provider. I would hire the second person unless we were the company specializing in address look up. There is nothing worse than a developer who doesn’t know the difference between which problems are part of the business domain that they are suppose to be writing code for and problems that other people have already solved. And for this particular use case, I happen to know about CASS certified software. SmartyPants is $1000/month for unlimited lookups. Why would I waste company resources on writing that myself? The yearly cost is less than a month’s fully allocated salary for a senior developer in a major metropolitan city.
- Jemaclus 8y ago
  Yep, exactly. :)
thirdsun 8y ago
> (In case you were wondering, the _real_ answer I'm hoping for is "I'd ask Google Maps." I've had exactly two people give me this response in the 8+ years I've been giving this challenge. I don't know if it's because they think it's a dumb answer, if they know that I expect a code-related answer, or if it never occurs to them... but I like to think someone who wants to see what Google says isn't the type that constantly wants to reinvent the wheel. Note that NOT giving this answer is not a deal-breaker. I generally give the benefit of the doubt to candidates here.) I'm surprised that this rarely seems to be brought up as a solution. It was the first approach I had in mind since you really can't split and format all those potentially mistyped addresses reliably without looking them up in a database/directory of valid addresses. It feels very obvious, however admittedly in an interview situation I might actually assume that the interviewer doesn't want me to use the third-party look up approach as it feels like cheating, which is somewhat absurd since it's the correct approach.
- Jemaclus 8y ago

dudul 8y ago

> I’m looking for them to find the right abstraction Nothing worse than an interviewer asking a design/coding question and who already "knows" which answer he/she wants.

jjoonathan 8y ago
Also, I'd give better than even odds that GP's "right" answer is a pet solution of theirs that other people of similar background and skill level would contest. I don't disagree with the practice of giving simple questions with solution spaces well understood by the interviewer. I use it myself. However, I force myself to accept any answer that correctly identifies tradeoffs as correct and I have to intentionally suppress my inclination towards a specific set of weights on those tradeoffs in order to be fair. This doesn't seem to be nearly as common as it ought to be.
adjkant 8y ago
This 100%. There's a big difference between looking for maintainable and extendable code and the "right" solution. To me, that almost no one passes is a red flag - if you are screening resumes right and framing the question right, the pass rate should be at least 25% IMO. Extensibility/maintainability also exist on a spectrum - a less than ideal answer can still be pretty close.
- Aeolun 8y ago
  I guess that could be said for any question. Have them be easy enough that at least 40% give something close to the desired answer, and then use 10 of those questions.
- baron816 8y ago
  I’m fine with less than idea answers. The problem is that most people I see prematurely optimize and don’t try to abstract the problem out at all. Or they only abstract one small part, or a part that makes no sense to abstract. They gravite to one big function that does everything. Our codebase has a lot of big functions that do everything. The only time people try to break things up is to make it DRY. Any time we need to change things, it breaks something else entirely unrelated.
  - adjkant 8y ago
    Based on the question you posted I'm honestly surprised, that one seems really straightforward. If you write it in a functional language it's basically impossible to mess up the design if you "make it work" only.
  - fao_ 8y ago
    > The problem is that most people I see prematurely optimize and don’t try to abstract the problem out at all. Have you ever heard of Premature Abstraction[0][0a]? > Our codebase has a lot of big functions that do everything. The only time people try to break things up is to make it DRY. That's the whole point of DRY, though[1]. If you abstract with less than three instances of it, you will end up with abstractions that typically misfit the solution, requiring refactoring or outright disposal of the abstraction in the future (Or worse). Also, you waste time developing (what in all likelyhood are bad or leaky) abstractions when you could be devoting time to something more important. > Any time we need to change things, it breaks something else entirely unrelated. That's unrelated to abstraction. There, I said it. Leaky or badly fitting interfaces are not solved by abstracting more, they're solved by compartmentalizing more (There's a subtle difference here). This can be done with abstraction, but doesn't need to be. Typically refactoring the data structures, shuffling state around, or redesigning the interfaces to better fit the problem, is a better solution. [0]: http://wiki.c2.com/?PrematureAbstraction http://wiki.c2.com/?PrematureAbstraction [0a]: http://wiki.c2.com/?TooMuchAbstraction http://wiki.c2.com/?TooMuchAbstraction [1]: http://wiki.c2.com/?ThreeStrikesAndYouRefactor http://wiki.c2.com/?ThreeStrikesAndYouRefactor
  - capsule_toy 8y ago
    I feel like this really depends on how the question is asked, how the interviewee is guided through the question, and the interviewer's expectations. If I was the interviewer, this would basically be a fizzbuzz question. The reason is that I'm pretty sure I'd have to basically tell the interviewee that I want a higher order function that takes in a predicate function. If the question is simply phrased, "Group the values by odds and evens ...; and please create an appropriate abstraction" without any more details, it would explain your results. I wouldn't be able to hold it against the interviewee that they couldn't reach the proper abstraction without more context. If I wanted to gauge an interviewee's ability with abstraction and code organization, my preference would probably be to engage in a higher level discussion, because it's difficult to construct a code test that tests this well.
LolNoGenerics 8y ago
My closing interview question for application programmers is about how to scale database. The answer is completely open, just to see how deep the person went in his career. The hidden part of it, is that I want to get some insight for myself.

scarface74 8y ago

Too many software engineers get into a mindset of “just make it work.” For me, making it work is only half the battle. You need to build something that will make it possible for you or someone else to come back to later and be able to reason about and modify or extend. There are no absolutes. In small companies that are just trying to get that one whale or feature that can keep them in business and prove to thier investors that they have achieved “product market fit”, sometimes just duck taping together makes sense. Other times companies aren’t looking for a long term product, just something good enough so the investors can have an exit strategy. Yes I have worked and been a Dev team lead in both the above environment and one that wanted well tested, well architected software that they wanted for the long term and had the resources to see it through. You have to know what the end game of the business is. Look at Twitter. All indications was that early on that their code base was horrible. They proved their was market, got the money and rearchicted thier system.

rizzom5000 8y ago
I think you make a valuable point here, but I don't think that quality and productivity are mutually exclusive. I often encounter engineers or teams who are putting just as much time and effort, or more, into 'making it work' as it would take a more skilled engineer or team to achieve both.
- scarface74 8y ago
  Most of the time they aren’t mutually exclusive. It’s just as fast for me to write maintainable code that is well designed and for me to write some scripts to automate deployment and Cloud Formation templates to automate infrastructure deployment. But I’m only one person. If they want something done fast, I can spin up a team of barely competent programmers who know how to create web pages that meet the spec and outsource a bunch of manual QA testers instead of writing automated test and let them test the code that we write during the day when they come to work while we are sleep (outsourced it’s daytime for them). Despite the talk of the 10x developer, sometimes you just need bodies. I can do front end, middle tier, database admin work, AWS net ops, dev ops, and development, talk to CxOs about strategy, mentor developers, lead a team etc. and I have done all of those things. But, I can’t do it all at once.
  - hayden592 8y ago
    Well said.

graycat 8y ago

IMHO, do all you want on (A) "declarative code" and (B) "find the right abstraction—one that will make it easy to extend the problem" and I will applaud. Indeed, as I entered grad school in applied math and had a good career going in software, two profs getting ready to teach a computing course asked what advice I would give. I responded with something like your (B). Also for (A), at times I tried to write code that would have some algebraic properties: E.g., as I was writing various sorting routines, routines to invert a permutation, to apply a permutation to an array, working with the fast Fourier transform, there were, of course for these topics, some cases where could regard calling one of the routines as something like an operator in parts of math/physics, get new operators by composing the other operators, and, then, saying when some of the operators were equal to some of the others,, net, nothing, or invert another one. I got some such before I got back to just get it done. But at this point, IMHO, for all can do on (A), (B), etc., my view is that the crucial part is missing: I urge to do all you can on (A), (B), etc. and then just take the attitude that the code doesn't mean anything at all, is just gibberish, and then get the important meaning by documentation in a natural language, e.g., English. E.g., in a physics text F = ma has with it one or more whole chapters of well written natural language explaining what the heck that equation and its symbols mean. We do not leave the math by itself as self-documenting, self-evident, clear, or any such thing. Then, write the documentation so well that, if had to select and keep just one of the code and the documentation, then definitely leap to keep the documentation: If the documentation is good, then can reconstruct the code fairly easily. Without the documentation, understanding the code well enough to reconstruct the documentation tends to be a really big puzzle problem and likely in principle impossible. Bluntly, knowledge and meaning are communicated in natural language. E.g., well written pure math is in complete sentences.