34 ms·

I'm a good engineer but I suck at building stuff

238 points by lbarrow 10y ago

jrumbut 10y ago
I feel like my experience is the opposite of this. I've never understood something until it stood between me and building what I needed to build. This approach has been great professionally, but lately I'm becoming more interested in theory intensive fields and struggling to find resources that teach from the perspective of someone who wants to build something that requires the knowledge involved, rather than someone who just wants that knowledge.
- amorphid 10y ago
  I'm often curious about the theory, or at least the "How do I do X?", bits of programming. What helps me is picking something I'm curious about, and then figuring out how to be curious about a smaller piece of it. Lately I've been curious about how I could go about building a web framework in Elixir. I started off buy spending this past Sunday digging into how to open sockets/ports, and send requests from my browser, and reply to them from the Elixir command line REPL.
- wonnage 10y ago
  I've been just like this - without the context of a problem to solve, theoretical things just don't click for me. Regex was a mystery and impossible to memorize until I had to write a matcher for a class, and I haven't forgotten since. Similarly, I never get stuck at work, because everything I learn has a problem behind it, but as soon as I go home and try to teach myself something for fun I derp out immediately.
  - saeranv 10y ago
    Why not integrate new things to learn with a fun side project?
    - 8note 10y ago
      coming up with side projects is difficult.
      - shade 10y ago
        Yeah, this is my problem as well. I have a really hard time coming up with ideas for a good side project, and then when I do, half the time I find out someone already implemented something like that and it feels like I'm just pointlessly reinventing the wheel. I think I need to do a better job of reminding myself that it's not pointless as long as I learn something.
        c22 10y ago
        Another reason it's not pointless is that diversity breeds resilience. Perhaps your implementation will sidestep some issue the pre-existing ones have or perhaps it will just appeal more to some people's workflow (likely yours at the very least!)
      - bpchaps 10y ago
        What worked for me was finding a civic problem that was annoying just enough to want to fix, no matter how large it is. You learn a lot from it, but it also gives you a chance to get more involved in civics, particularly from the projects that stem off. Since the motivation is in helping your community out, it gives a little extra motivation and joy. The projects kind of build on themselves since the rabbit holes go so deep. For example, I'm working on plotting parking tickets in Chicago. Tons of FOIA, lots of data analysis, sanitizing, python, GIS, government induced hair pullings, gnu cli tools, civic meetups, web scraping, etc. Finished this[0] last night using 730k parking tickets after a LOT of cleanup with python. There's no way in hell I would've been able to do this a year ago without stepping into something so deep. [0] https://plot.ly/~red-bin/6.embed https://plot.ly/~red-bin/6.embed (just
        lightcatcher 10y ago
        Are you located in Chicago? If so, sounds like your project would fit in perfectly at ChiHackNight: http://chihacknight.org/ http://chihacknight.org/ I'm guessing that you are already familiar with ChiHackNight, but if not I recommend checking it out.
- robohamburger 10y ago
  I agree! I have a hard time focusing on something that is purely academic unless said academic thing seems to have a property I want to explore on my own or use to build something. I got several C's in calculus because I was too busy messing with slightly different calculus instead of doing the problem sets for the tests. I regret nothing, but I wish I could learn the same way most people seem to be able to sometimes.
  - jasonm23 10y ago
    Don't wish that, you have personalised learning for internal goals over grades. You will continue learning for your whole lifetime. While some others will need approval incentives just to pick up a book.
- JimboOmega 10y ago
  I'm always worried that it's not great for me professionally. Because the "cool kids" are always off learning the hot new thing, and I can do what I need to in the "old" thing, and so I don't learn the hot new thing. Aren't I, as an engineer, supposed to be constantly entranced by the bleeding edge of technology? Whether it's the latest lisp Dialect, the latest functional programming language, the latest NoSQL database, or whatever the latest is? Granted the nature of my work is such that I wind up using tons of new technologies every new year, but I don't go out and experiment with them with no particular use in mind.
  - morgante 10y ago
    You can build in the hot new thing though. I'm also a very practical learner. It's hard for me to pick up anything (whether it's a language, technique or a theory) without applying it. So to pick up new technologies I constantly cycle them into new projects.
    - JimboOmega 10y ago
      I can, but I won't build in the hot new thing for the sake of the hot new thing alone. What that tends to mean is that when I'm looking for a new job, my skills at old company are in old thing, while everyone is excited about hot new thing. This is typically most obvious with javascript libraries.
  - khedoros 10y ago
    This resonates with me. A lot of my tools update, and I eventually find good uses for the new/changed capabilities, but unless I have a particular use in mind, or unless it provides a concrete benefit, it's hard to chase after the new-shiny.
  - jrumbut 10y ago
    I'm mixed on this myself. The way I look at it is that since I am more focused on results, I'm always looking for new tools that will do more of the work for me. That said, I get what you're saying. Often it's clear the new fad doesn't provide much utility. In those cases it's like waiting for a cold to be over.
- saeranv 10y ago
  I am like this too. For me, I find that using a curriculum as a means to an end does three things: 1. Applying your knowledge forces you to confront the gaps or uncertainties in your understanding that you would normally overlook. 2. Allows you to interleave different the topic with related subjects, which gives you a broader or more fundamental understanding of the topic. 3. Attaches an immediate utility value to your study regime, which serves as a better motivator and means to identify when to study hard and go deep, and when to gloss over.
- notduncansmith 10y ago
  If you have the patience, a few deep Google/Wikipedia sessions can do wonders, followed by a subscription to Pluralsight to learn whatever hard skills you might need. In my case, I'm backfilling my linear algebra / set theory / statistics learning with Coursera and Wikipedia while learning R and some NN stuff with Pluralsight. I'm trying to build something specific with it (facial recognition) so I'm also learning about that in depth (mostly through Google -> blogs/WP/articles/products/open-source). Just trying to fully comprehend the READMEs and docs of projects that look useful has given me a lot of leads. FWIW all this math stuff a) makes way more sense with some FP knowledge, and b) is not all that hard to understand in the context of a project. Finally, for extra immersion, start reading Data Tau (the data science version of HN). Just pick out stuff that's related to what you're working on, and then try to understand a whole article or something. That's what I did with HN and I grew exponentially as a programmer because of it.
daenz 10y ago
> When I try to build something new, I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object's dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth. Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the best, most natural expression of the ideas it contains -- obsessing, like Catt said, over my own construct, rather than on the thing my code does. I used to be like this for the first few years of programming. And I knew a guy at my last job who was exactly like this. The thing that helped me, when I felt the indecision paralysis come on, is to just do something and accept that it may be wrong. You often don't know the best decision in the first place because you lack experience. Doing it the right way by accident, or making the mistake of picking the wrong way helps get you that experience. Be deliberate about always doing something, and over time the paralysis will get less and less as you gain more experience.
- user_0001 10y ago
  Depends on your industry and where you work obviously. But I have a strict "that will do" policy. If it looks like it might work, that will do. It won't' be well engineered, it will be buggy. But the project will be completed and released. If it makes some sales and looks like it has some traction, then I go back and visit the many (many) //todo - clean this up and refactor everything out. Usually after a while of adding more features, hacking out nasty design decisions the best way on how to do it comes to the fore naturally.
  - ProAm 10y ago
    I agree with this philosophy as well. If is a project or program that will be worked on more as time progresses, typically it refactors itself after the programmer has a better grasp of the big picture. Often the bigger picture can only be grasped after there is some momentum with the project. I'd say this works 90% of the time, where the other 10% needs more upfront design and research done before any real work is started.
    - 10y ago
abc_lisper 10y ago
You just a need priority list. If you think something needs to be fixed, add it to the list. Choose the next task with the highest priority when you are done with the current one. At least you will know why you didn't fix something. It would be most likely be because there are only so many hours in a day, and your skill does not change overnight, despite obsessing over it.
ogreveins 10y ago
Here's a priority list that you should typically follow for making anything. 1. Make it work. 2. Make it not break. 3. Make it fast. That's it really. Until the performance of something is blocking what you need to do somewhere else leave it the hell alone.
- reefoctopus 10y ago
  4. Make it manageable.
  - ianstormtaylor 10y ago
    I'd probably swap them: 1. Make it work. 2. Make it not break. 3. Make it manageable. 4. Make it fast. Otherwise I find that trying to make something fast before making it manageable usually ends up in crazy hacks that are hard to undo later.
    - ogreveins 10y ago
      I'd agree with this. My last couple of projects did have a couple of hacks that bordered on spaghetti code until they were sufficiently cleaned up.
    - stevetrewick 10y ago
      3.5 Profile it to see whether or not it needs to be faster
      - voltagex_ 10y ago
        If you profile it on a fast machine, your results might lie to you.
        douche 10y ago
        Or on a machine on a fast network, or SSD vs spinning-rust, or any number of varying factors.
deleted 10y ago
[deleted]
scottious 10y ago
God I wish the rest of my team would read this... I feel like they're more concerned with what stupid monad to use or how to create a really deeply nested class hierarchy than making features and bug fixes that deliver value to people who use the software
- swanson 10y ago
  Why not link it to them and then discuss it over a team lunch?
  - scottious 10y ago
    That makes too much sense! Honestly though, the fact that that seemingly obvious suggestion is actually quite difficult means there's something wrong with me or our team culture... something to think about I guess.
mkoble11 10y ago
the critical self talk is normal. you should watch seth godin's talk "quieting the lizard brain" https://vimeo.com/5895898 https://vimeo.com/5895898 i just had a similar conversation, but it dealt with music instead of code. this person felt they couldn't improvise/ create. the problem isn't with their abilities, it's that they were taught to follow instructions - like the notes on sheet music. jazz musicians play off what they hear instead. however, they first internalized the rules and then forgot them. you've already got the rules down - so the next step is to "forget" them. a time constraint like going to a hackathon is a good place to start. you're pushing yourself to create in a short amount of time. here, you'll focus on shipping...drowning out the critical voice in your head. it's much like a muscle. the more you build and struggle through, the stronger you'll get.
- munchbunny 10y ago
  Very much this. If you force yourself to make lots of things at a fast pace, whether by hackathon or something else, you will eventually get over your hesitations, and you'll find yourself speeding up and building better things too.
hyuuu 10y ago
and it doesnt end there, after you build the stuff, you need to make sure that the stuff solves a problem, which to me is a much more harder problem.
- elihu 10y ago
  That's a good point. Also, in the process of solving one problem you may discover a more interesting, more relevant, more general, or more universal problem you could be solving instead.
rileymat2 10y ago
I find this is a problem when I lack control over what I am building, so I focus on the act of building it which is in my control.
zer00eyz 10y ago
There is a quote from Louis Nizer that applies here: "He who works with his hands is a laborer. He who works with his hands and his head is a craftsman. He who works with his hands and his head and his heart is an artist." Its that last part that is hard to bridge for a lot of engineers. The thing that did it for me was sitting through a LOT of formal usability studies. Seeing folks actually use an application you made, where they make mistakes, get stuck, will change your relationship with your code. Even if you work purely on the back end building APIs, you have customers (other developers in this case). Focus on the what the code does, and why someone would use it, care about your customer... the how only matters to your fellow engineer, and if it is that bad they are going to give you grief for it and you can fix it.
- deleted 10y ago
  [deleted]
- humanrebar 10y ago
  > ...and if it is that bad they are going to give you grief for it and you can fix it. You can't always fix it. If it were that simple, everyone would be using Python 3 already.
  - zer00eyz 10y ago
    I think the argument could be made that python 3 is an example of "great engineering" and (in hindsight) "poor customer understanding". Python 3 is the polar opposite to Linus' meltdown on not breaking user space see: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75 Sadly I like Python 3 and wish it was more popular.
    - BuckRogers 10y ago
      I see Python3 as poor engineering. There are no technical reasons why you can't run bytecode from both 2 and 3 together. Various JVMs and the CLR solved this problem. They created their own problem by refusing to built or maintain a comprehensive solution. As well, there's nothing in Python3 that didn't already exist in the Python2 ecosystem or was trivial to add to Python2 (backport or otherwise). Thus many of us see CPython3 as technical churn rather than technical innovation. I share your sentiment about having 1 version of Python but it's not the users fault. It's the core dev team's and Guido's.
kstenerud 10y ago
Learning the programming art is like learning any other art. You first learn the rules (and even more importantly the REASON behind the rules). You then build the discipline of applying the rules. And finally through experience you learn where some of the rules just don't apply. The usual progression is something like: 1. Build your first major project as senior engineer. You make something that works, but is brittle and soon becomes difficult to work with. 2. Build your second major project. This time, you adhere to ALL established best practices. The end product is difficult to configure because you've gone too far in flexibility, and a major pain to maintain because the codebase is 3x larger than it needed to be, and filled to the brim with boilerplate code. You also resist changes that threaten the precious architecture. Everything's perfectly isolated and testable, though! 3. Build your third major project with the minimum needed to get it to work for your client, keeping a few of the best practices to keep it mostly flexible enough for changing requirements. It will eventually grow in unhealthy ways as requirements shift beyond fundamental architectural assumptions, but you already knew this going in. 4. Make the mistake of doing a "2.0" rewrite of your major project. Vow never to do it again.
bikamonki 10y ago
What is a good engineer?
ThePhysicist 10y ago
I think there is a lot of truth here. Recently I had to work with some old code of mine that I wrote ten years ago as a (Physics) student, and looking at the code I realized that while it was a bit ugly and "unconventional" it worked quite well. If I would start the same project today (after five years of intense software dev experience) I think I would be at a much higher risk of "writer's block", simply because I think of so many aspects of the code (testing, deployment, architecture, documentation, language, tooling, framework) that were just unknown to me at the time and which therefore did not distract me. So in a sense, ignorance really is a bliss. Here's the code in case you're interested, it's for simulating superconducting circuits: https://github.com/adewes/superconductor https://github.com/adewes/superconductor
vosbert 10y ago
There's a couple modes of engineering mindsets I'm conscious of. 1) Being careful of every change and addition I make. Trying to figure out and predict the effects, scalability, and maintainability of the code I produce. I find that most engineering positions are looking for this, as most employers already have an existing production code base and would not like wild things like crashes and service disruptions to happen to their audience. 2) Occasionally, I get to start on something completely new. Not new as in just a blank page, but new as in blank project, or even blank idea. As exciting as this sounds, over 90% of the time, the idea will die as there is some undiscovered flaw or expectation almost always external to an exceptionally well thought out implementation. The only thing clear about this is the urgency of the deadline, and the failure associated with missing it (missed management expectations, no demo, no presentation... etc). Many know this as building a Minimum Viable Product. In this case, all rules go out the window. Choose expedient tools, create copious crap code and internal design, as long as it works OKish in the end. Having it violently done tomorrow as opposed to 3 days later, or a week later, or a month later, is key. If you're lucky and it limps along (not canned as uninteresting), just change hats and become the step (1) engineer. Sounds like you desire some more experience with (2), but both types of people are needed. You, yourself, will become more valuable if you can put on both hats, but I wouldn't say that one hat is absolutely better than the other.
deleted 10y ago
[deleted]
xyzzy4 10y ago
"He who rests while other people work with their heads, hands, and hearts is a capitalist".
- dang 10y ago
  We detached this subthread from https://news.ycombinator.com/item?id=11669954 https://news.ycombinator.com/item?id=11669954 and marked it off-topic.
- 0xdeadbeefbabe 10y ago
  Or an HN commentator.
  - stoic 10y ago
    Back to work.
- 6stringmerc 10y ago
  That quote certainly describes my view of the legacy of Steve Jobs at the cold, pragmatic core.
  - zer00eyz 10y ago
    >Steve Jobs at the cold, pragmatic core. This is probably the best description of what we see of him that I have ever seen. Combine that with his verbal judo and one should not be shocked that he was successful. But I don't think his legacy is one of resting.
  - mwfunk 10y ago
    Just because a CEO spends their day making high-level decisions because they are literally delegating tasks to tens of thousands of people doesn't mean that they are "resting".
  - PhasmaFelis 10y ago
    Just don't make the mistake of thinking that it was only Steve Jobs. He just happened to be more visible than most.
groby_b 10y ago
Meanwhile, I've seen way too much code from people who're good at building things, but not engineering. And lost countless nights to keeping these rickety structures alive long enough that we could fix the most egregious issues. Sure, build something, anything, to show it can be done. THEN MAKE SURE ITS ACTUALLY STABLE. And then realize that building stuff, and understanding how to build it well, both matter.
cagey_vet 10y ago
the first step to curing your problem is realizing you have one.
jluxenberg 10y ago
Slides from @cattsmall keynote mentioned in the article: http://www.slideshare.net/CattSmall/con-the-creative-programmer http://www.slideshare.net/CattSmall/con-the-creative-program...
pedalpete 10y ago
Where you see your greatest weakness, I see your great strength. I'm good at building stuff, but I'm not a great engineer (I'm ok, but others on my team are way better). Not to say I don't have my strengths. I'm good at figuring out what to build and the general architecture of how to get it done quickly and working well. But when it really comes time to scale and scale big, you don't want me coding. You want me looking at the next features etc. etc. If you love getting into the nitty-gritty of high quality beautifully considered easy to work with code, why do you feel you should focus on 'building stuff'? Personally, I think focusing on your strength (not to completely ignore building stuff) can be a huge benefit.
sjg007 10y ago
Meh. It should meet the requirements. And at any rate the next dev to work on your code will declare that it stinks and needs to be refactored at best or completely rewritten.
phantom_package 10y ago
Funny, I'm great at building stuff but I wouldn't consider myself an amazing engineer.
nanodano 10y ago
Another thing I run in to a lot is people saying "I know how to program, but I don't know what to build." There is an amount of creativity involved with programminng. It's like learning how to physically manipulate a guitar and play notes, but saying "I don't know what to play." That happens a lot too, but musicians have the repetoire of other composers to play if they do not want to write their own music (many don't). With programming, recoding something is called reinventing the wheel and that's frowned upon. Ok, sometimes the analogies are forced, but I hope you get it! It's kind of interesting though, because in order to progress we have to build something new, or build on top of what we have, so the technology is forced to evolve. Music can repeat over and over and people don't get tired of it and you could argue pop music is working against the evolution of music. For anyone who hasn't seen the four chord song... https://www.youtube.com/watch?v=oOlDewpCfZQ https://www.youtube.com/watch?v=oOlDewpCfZQ Wait, what we were originally talking about now?
cyberpanther 10y ago
A lot of times as engineers we don't have to build anything. We only have to fix, maintain, or tweak. Or maybe build just a very small piece of something. So it's perfectly OK for most of us to suck at building stuff. But on a team it's important someone fill that role. But most of us shouldn't or it would be chaos.
agentultra 10y ago
Good advice! If we really cared about the systems we create and the effect they have on the world then the language it is programmed in and the implementation of that system would only be one part of the process. The means of effective reasoning about the design of software systems is formal. However it seems to be outside the scope of any introduction to computer science or programming course. To quote Friedrich Bauer: "Software engineering is the part of computer science which is too difficult for the computer scientist."
elishacook 10y ago
I can relate to this. You see it in a lot of domains. I see two concepts that apply: Practice/Performance and Generation/Synthesis. To be a musician you must practice, but you must also perform. These are two different modes. When practicing, the goal is to improve a specific technical skill. You don't concern yourself with expression at all. You will repeat the same passages over and over and many exercises sound really terrible. When you perform, you put your trust in your training and you access an intuitive part of yourself to add feeling and nuance to your playing. In design thinking, it is common to split activities into generation and synthesis. When generating, you recklessly explore possiblities, tossing them out, following blind alleys, making weird connections. Synthesis is the process of evaluating the generated ideas against some framework, such as goals or known models, finding patterns, simplifying and making coherent. We need all of it: practice, performance, generation and synthesis. Experience brings a sense of when each mode is appropriate or needed. Being explicit about which mode you are working in removes the stress from attempting to practice while you are generating or similar dissonant mixes. More concretely, a user-centered process has brought a lot of this mental framework to development for me. Step one is never setting up a test harness, it's understanding the user and their goals, even if the user is yourself. Everything else flows much more easily from this starting point. You can base your decisions on how they will affect the user instead of on "best" practices that may not have the best outcome in your situation. Things like precision, speed, fidelity, automation, complexity, stability, even whether or not to build something--all involve trade offs that affect the user in different ways. You can experiment more freely knowing that you will evaluate your experiments in terms of their utility for the user. The art is in applying this left-brain-right-brain dance to trace a path through all the complexity on behalf of the user.
Jach 10y ago
"Just do it, hack! I approach code like games, rush deep into room, trigger all NPCs, die, after respawn I know where NPCs are." https://twitter.com/bkaradzic/status/494341136245211137 https://twitter.com/bkaradzic/status/494341136245211137
dschiptsov 10y ago
Whether or not one is good is for other people to decide by evaluating one's deeds.
horsecaptin 10y ago
I have the opposite problem. I'm great a building stuff... but I suck at passing job interviews.
thisisadumb 10y ago
i am a good engineer but i am a bad engineer!?
chipsy 10y ago
I like this post because it captures some way in which my perspective has changed over time. Engineering was something I saw as a way to perhaps "cheat" at product problems because if I made a good enough/fast enough/automated enough/generic enough solution, I would be able to iterate on it really fast and so somehow come out ahead of people who went directly towards the simple solution. This mentality was clearly inspired by years of homework being a task that would never go away and that I desperately wanted to get out of my life as fast as possible in the way that consumer products advertise their elimination of household tasks - ergo my goal as a student was to wish I could automate away all aspects of my studies. I would look for any kind of secret trick or forgotten technique that would get me closer to that goal at minimum effort. All the while I would build very little that was finished and get lost in maximizing my use of silver-bullet abstraction. I've eventually come around to flipping this idea on its head, though. If I design not just some kind of product or solution, but a whole process, starting basically with how I want to run my life and then drilling into specific details from there, the technical knowledge stands on more even ground with other forms of knowledge, and with seeing life itself in a more precious sense. With that mindset, good scheduling of every day as an end in itself grows vastly more important, and abstraction-for-its-own-sake falls away: All programming problems start by assuming they are solved first with "code that looks like breadboard wiring" [0] and then working up the abstraction ladder from there. Automating the technical parts of the solution won't guarantee that it's right in any other way, but it will ease the pain of changing the specification. Acknowledging that the problem is messy, that breadboard coding is messy, and that I won't know how to solve everything immediately and cannot depend on a silver bullet, all constitute crucial first steps. Now I always look for really basic groundwork to be laid out early on - typically, transforming the breadboard code into something that uses a new data structure, or generating the code flow from a stack or a list or a tree - and that no shortcut is possible without compromising the ability of a potential future abstraction - that it just takes a lot of layers to get where I want to go. Breadboard code is assumed to be ideal until demonstrated otherwise, while "x in y lines" hype is to be avoided under the assumption that the solution is brittle and over-modeled towards the demo code. I cannot assume that my valuable production code will need x or work in y lines. I don't abstain from adding dependencies, but I will preference towards copy-paste-own when I find a reason to reuse code. [0] http://www.instructables.com/id/How-to-Build-an-8-Bit-Computer/ http://www.instructables.com/id/How-to-Build-an-8-Bit-Comput...
dmarges 10y ago
One thing that really threw me for a loop was back when I started learning about TDD. I tried to apply it to literally everything I coded. This caused a lot of paralysis because I was worried about whether I was testing the right way. Over time I came to a compromise. Basically, if I have a good understanding of the design and what I want to build and I know it is going into Production I use TDD. If I'm not entirely sure what I am building or I'm exploring an idea or spiking/prototyping something then I just write the code with little regard for things like speed or design patterns.

238 points by lbarrow 10y ago

I feel like my experience is the opposite of this. I've never understood something until it stood between me and building what I needed to build. This approach has been great professionally, but lately I'm becoming more interested in theory intensive fields and struggling to find resources that teach from the perspective of someone who wants to build something that requires the knowledge involved, rather than someone who just wants that knowledge.

amorphid 10y ago
I'm often curious about the theory, or at least the "How do I do X?", bits of programming. What helps me is picking something I'm curious about, and then figuring out how to be curious about a smaller piece of it. Lately I've been curious about how I could go about building a web framework in Elixir. I started off buy spending this past Sunday digging into how to open sockets/ports, and send requests from my browser, and reply to them from the Elixir command line REPL.
wonnage 10y ago
I've been just like this - without the context of a problem to solve, theoretical things just don't click for me. Regex was a mystery and impossible to memorize until I had to write a matcher for a class, and I haven't forgotten since. Similarly, I never get stuck at work, because everything I learn has a problem behind it, but as soon as I go home and try to teach myself something for fun I derp out immediately.
- saeranv 10y ago
  Why not integrate new things to learn with a fun side project?
  - 8note 10y ago
    coming up with side projects is difficult.
    - shade 10y ago
      Yeah, this is my problem as well. I have a really hard time coming up with ideas for a good side project, and then when I do, half the time I find out someone already implemented something like that and it feels like I'm just pointlessly reinventing the wheel. I think I need to do a better job of reminding myself that it's not pointless as long as I learn something.
      - c22 10y ago
        Another reason it's not pointless is that diversity breeds resilience. Perhaps your implementation will sidestep some issue the pre-existing ones have or perhaps it will just appeal more to some people's workflow (likely yours at the very least!)
    - bpchaps 10y ago
      What worked for me was finding a civic problem that was annoying just enough to want to fix, no matter how large it is. You learn a lot from it, but it also gives you a chance to get more involved in civics, particularly from the projects that stem off. Since the motivation is in helping your community out, it gives a little extra motivation and joy. The projects kind of build on themselves since the rabbit holes go so deep. For example, I'm working on plotting parking tickets in Chicago. Tons of FOIA, lots of data analysis, sanitizing, python, GIS, government induced hair pullings, gnu cli tools, civic meetups, web scraping, etc. Finished this[0] last night using 730k parking tickets after a LOT of cleanup with python. There's no way in hell I would've been able to do this a year ago without stepping into something so deep. [0] https://plot.ly/~red-bin/6.embed https://plot.ly/~red-bin/6.embed (just
      - lightcatcher 10y ago
        Are you located in Chicago? If so, sounds like your project would fit in perfectly at ChiHackNight: http://chihacknight.org/ http://chihacknight.org/ I'm guessing that you are already familiar with ChiHackNight, but if not I recommend checking it out.
robohamburger 10y ago
I agree! I have a hard time focusing on something that is purely academic unless said academic thing seems to have a property I want to explore on my own or use to build something. I got several C's in calculus because I was too busy messing with slightly different calculus instead of doing the problem sets for the tests. I regret nothing, but I wish I could learn the same way most people seem to be able to sometimes.
- jasonm23 10y ago
  Don't wish that, you have personalised learning for internal goals over grades. You will continue learning for your whole lifetime. While some others will need approval incentives just to pick up a book.
JimboOmega 10y ago
I'm always worried that it's not great for me professionally. Because the "cool kids" are always off learning the hot new thing, and I can do what I need to in the "old" thing, and so I don't learn the hot new thing. Aren't I, as an engineer, supposed to be constantly entranced by the bleeding edge of technology? Whether it's the latest lisp Dialect, the latest functional programming language, the latest NoSQL database, or whatever the latest is? Granted the nature of my work is such that I wind up using tons of new technologies every new year, but I don't go out and experiment with them with no particular use in mind.
- morgante 10y ago
  You can build in the hot new thing though. I'm also a very practical learner. It's hard for me to pick up anything (whether it's a language, technique or a theory) without applying it. So to pick up new technologies I constantly cycle them into new projects.
  - JimboOmega 10y ago
    I can, but I won't build in the hot new thing for the sake of the hot new thing alone. What that tends to mean is that when I'm looking for a new job, my skills at old company are in old thing, while everyone is excited about hot new thing. This is typically most obvious with javascript libraries.
- khedoros 10y ago
  This resonates with me. A lot of my tools update, and I eventually find good uses for the new/changed capabilities, but unless I have a particular use in mind, or unless it provides a concrete benefit, it's hard to chase after the new-shiny.
- jrumbut 10y ago
  I'm mixed on this myself. The way I look at it is that since I am more focused on results, I'm always looking for new tools that will do more of the work for me. That said, I get what you're saying. Often it's clear the new fad doesn't provide much utility. In those cases it's like waiting for a cold to be over.
saeranv 10y ago
I am like this too. For me, I find that using a curriculum as a means to an end does three things: 1. Applying your knowledge forces you to confront the gaps or uncertainties in your understanding that you would normally overlook. 2. Allows you to interleave different the topic with related subjects, which gives you a broader or more fundamental understanding of the topic. 3. Attaches an immediate utility value to your study regime, which serves as a better motivator and means to identify when to study hard and go deep, and when to gloss over.
notduncansmith 10y ago
If you have the patience, a few deep Google/Wikipedia sessions can do wonders, followed by a subscription to Pluralsight to learn whatever hard skills you might need. In my case, I'm backfilling my linear algebra / set theory / statistics learning with Coursera and Wikipedia while learning R and some NN stuff with Pluralsight. I'm trying to build something specific with it (facial recognition) so I'm also learning about that in depth (mostly through Google -> blogs/WP/articles/products/open-source). Just trying to fully comprehend the READMEs and docs of projects that look useful has given me a lot of leads. FWIW all this math stuff a) makes way more sense with some FP knowledge, and b) is not all that hard to understand in the context of a project. Finally, for extra immersion, start reading Data Tau (the data science version of HN). Just pick out stuff that's related to what you're working on, and then try to understand a whole article or something. That's what I did with HN and I grew exponentially as a programmer because of it.

daenz 10y ago

> When I try to build something new, I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object's dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth. Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the best, most natural expression of the ideas it contains -- obsessing, like Catt said, over my own construct, rather than on the thing my code does. I used to be like this for the first few years of programming. And I knew a guy at my last job who was exactly like this. The thing that helped me, when I felt the indecision paralysis come on, is to just do something and accept that it may be wrong. You often don't know the best decision in the first place because you lack experience. Doing it the right way by accident, or making the mistake of picking the wrong way helps get you that experience. Be deliberate about always doing something, and over time the paralysis will get less and less as you gain more experience.

user_0001 10y ago
Depends on your industry and where you work obviously. But I have a strict "that will do" policy. If it looks like it might work, that will do. It won't' be well engineered, it will be buggy. But the project will be completed and released. If it makes some sales and looks like it has some traction, then I go back and visit the many (many) //todo - clean this up and refactor everything out. Usually after a while of adding more features, hacking out nasty design decisions the best way on how to do it comes to the fore naturally.
- ProAm 10y ago
  I agree with this philosophy as well. If is a project or program that will be worked on more as time progresses, typically it refactors itself after the programmer has a better grasp of the big picture. Often the bigger picture can only be grasped after there is some momentum with the project. I'd say this works 90% of the time, where the other 10% needs more upfront design and research done before any real work is started.
  - 10y ago

abc_lisper 10y ago

You just a need priority list. If you think something needs to be fixed, add it to the list. Choose the next task with the highest priority when you are done with the current one. At least you will know why you didn't fix something. It would be most likely be because there are only so many hours in a day, and your skill does not change overnight, despite obsessing over it.

ogreveins 10y ago

Here's a priority list that you should typically follow for making anything. 1. Make it work. 2. Make it not break. 3. Make it fast. That's it really. Until the performance of something is blocking what you need to do somewhere else leave it the hell alone.

reefoctopus 10y ago
4. Make it manageable.
- ianstormtaylor 10y ago
  I'd probably swap them: 1. Make it work. 2. Make it not break. 3. Make it manageable. 4. Make it fast. Otherwise I find that trying to make something fast before making it manageable usually ends up in crazy hacks that are hard to undo later.
  - ogreveins 10y ago
    I'd agree with this. My last couple of projects did have a couple of hacks that bordered on spaghetti code until they were sufficiently cleaned up.
  - stevetrewick 10y ago
    3.5 Profile it to see whether or not it needs to be faster
    - voltagex_ 10y ago
      If you profile it on a fast machine, your results might lie to you.
      - douche 10y ago
        Or on a machine on a fast network, or SSD vs spinning-rust, or any number of varying factors.

deleted 10y ago

[deleted]

scottious 10y ago

God I wish the rest of my team would read this... I feel like they're more concerned with what stupid monad to use or how to create a really deeply nested class hierarchy than making features and bug fixes that deliver value to people who use the software

swanson 10y ago
Why not link it to them and then discuss it over a team lunch?
- scottious 10y ago
  That makes too much sense! Honestly though, the fact that that seemingly obvious suggestion is actually quite difficult means there's something wrong with me or our team culture... something to think about I guess.

mkoble11 10y ago

the critical self talk is normal. you should watch seth godin's talk "quieting the lizard brain" https://vimeo.com/5895898 https://vimeo.com/5895898 i just had a similar conversation, but it dealt with music instead of code. this person felt they couldn't improvise/ create. the problem isn't with their abilities, it's that they were taught to follow instructions - like the notes on sheet music. jazz musicians play off what they hear instead. however, they first internalized the rules and then forgot them. you've already got the rules down - so the next step is to "forget" them. a time constraint like going to a hackathon is a good place to start. you're pushing yourself to create in a short amount of time. here, you'll focus on shipping...drowning out the critical voice in your head. it's much like a muscle. the more you build and struggle through, the stronger you'll get.

munchbunny 10y ago
Very much this. If you force yourself to make lots of things at a fast pace, whether by hackathon or something else, you will eventually get over your hesitations, and you'll find yourself speeding up and building better things too.

hyuuu 10y ago

and it doesnt end there, after you build the stuff, you need to make sure that the stuff solves a problem, which to me is a much more harder problem.

elihu 10y ago
That's a good point. Also, in the process of solving one problem you may discover a more interesting, more relevant, more general, or more universal problem you could be solving instead.

rileymat2 10y ago

I find this is a problem when I lack control over what I am building, so I focus on the act of building it which is in my control.

zer00eyz 10y ago

There is a quote from Louis Nizer that applies here: "He who works with his hands is a laborer. He who works with his hands and his head is a craftsman. He who works with his hands and his head and his heart is an artist." Its that last part that is hard to bridge for a lot of engineers. The thing that did it for me was sitting through a LOT of formal usability studies. Seeing folks actually use an application you made, where they make mistakes, get stuck, will change your relationship with your code. Even if you work purely on the back end building APIs, you have customers (other developers in this case). Focus on the what the code does, and why someone would use it, care about your customer... the how only matters to your fellow engineer, and if it is that bad they are going to give you grief for it and you can fix it.

deleted 10y ago
[deleted]
humanrebar 10y ago
> ...and if it is that bad they are going to give you grief for it and you can fix it. You can't always fix it. If it were that simple, everyone would be using Python 3 already.
- zer00eyz 10y ago
  I think the argument could be made that python 3 is an example of "great engineering" and (in hindsight) "poor customer understanding". Python 3 is the polar opposite to Linus' meltdown on not breaking user space see: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75 Sadly I like Python 3 and wish it was more popular.
  - BuckRogers 10y ago
    I see Python3 as poor engineering. There are no technical reasons why you can't run bytecode from both 2 and 3 together. Various JVMs and the CLR solved this problem. They created their own problem by refusing to built or maintain a comprehensive solution. As well, there's nothing in Python3 that didn't already exist in the Python2 ecosystem or was trivial to add to Python2 (backport or otherwise). Thus many of us see CPython3 as technical churn rather than technical innovation. I share your sentiment about having 1 version of Python but it's not the users fault. It's the core dev team's and Guido's.

kstenerud 10y ago

Learning the programming art is like learning any other art. You first learn the rules (and even more importantly the REASON behind the rules). You then build the discipline of applying the rules. And finally through experience you learn where some of the rules just don't apply. The usual progression is something like: 1. Build your first major project as senior engineer. You make something that works, but is brittle and soon becomes difficult to work with. 2. Build your second major project. This time, you adhere to ALL established best practices. The end product is difficult to configure because you've gone too far in flexibility, and a major pain to maintain because the codebase is 3x larger than it needed to be, and filled to the brim with boilerplate code. You also resist changes that threaten the precious architecture. Everything's perfectly isolated and testable, though! 3. Build your third major project with the minimum needed to get it to work for your client, keeping a few of the best practices to keep it mostly flexible enough for changing requirements. It will eventually grow in unhealthy ways as requirements shift beyond fundamental architectural assumptions, but you already knew this going in. 4. Make the mistake of doing a "2.0" rewrite of your major project. Vow never to do it again.

bikamonki 10y ago

What is a good engineer?

ThePhysicist 10y ago

I think there is a lot of truth here. Recently I had to work with some old code of mine that I wrote ten years ago as a (Physics) student, and looking at the code I realized that while it was a bit ugly and "unconventional" it worked quite well. If I would start the same project today (after five years of intense software dev experience) I think I would be at a much higher risk of "writer's block", simply because I think of so many aspects of the code (testing, deployment, architecture, documentation, language, tooling, framework) that were just unknown to me at the time and which therefore did not distract me. So in a sense, ignorance really is a bliss. Here's the code in case you're interested, it's for simulating superconducting circuits: https://github.com/adewes/superconductor https://github.com/adewes/superconductor

vosbert 10y ago

There's a couple modes of engineering mindsets I'm conscious of. 1) Being careful of every change and addition I make. Trying to figure out and predict the effects, scalability, and maintainability of the code I produce. I find that most engineering positions are looking for this, as most employers already have an existing production code base and would not like wild things like crashes and service disruptions to happen to their audience. 2) Occasionally, I get to start on something completely new. Not new as in just a blank page, but new as in blank project, or even blank idea. As exciting as this sounds, over 90% of the time, the idea will die as there is some undiscovered flaw or expectation almost always external to an exceptionally well thought out implementation. The only thing clear about this is the urgency of the deadline, and the failure associated with missing it (missed management expectations, no demo, no presentation... etc). Many know this as building a Minimum Viable Product. In this case, all rules go out the window. Choose expedient tools, create copious crap code and internal design, as long as it works OKish in the end. Having it violently done tomorrow as opposed to 3 days later, or a week later, or a month later, is key. If you're lucky and it limps along (not canned as uninteresting), just change hats and become the step (1) engineer. Sounds like you desire some more experience with (2), but both types of people are needed. You, yourself, will become more valuable if you can put on both hats, but I wouldn't say that one hat is absolutely better than the other.

deleted 10y ago

[deleted]

xyzzy4 10y ago

"He who rests while other people work with their heads, hands, and hearts is a capitalist".

dang 10y ago
We detached this subthread from https://news.ycombinator.com/item?id=11669954 https://news.ycombinator.com/item?id=11669954 and marked it off-topic.
0xdeadbeefbabe 10y ago
Or an HN commentator.
- stoic 10y ago
  Back to work.
6stringmerc 10y ago
That quote certainly describes my view of the legacy of Steve Jobs at the cold, pragmatic core.
- zer00eyz 10y ago
  >Steve Jobs at the cold, pragmatic core. This is probably the best description of what we see of him that I have ever seen. Combine that with his verbal judo and one should not be shocked that he was successful. But I don't think his legacy is one of resting.
- mwfunk 10y ago
  Just because a CEO spends their day making high-level decisions because they are literally delegating tasks to tens of thousands of people doesn't mean that they are "resting".
- PhasmaFelis 10y ago
  Just don't make the mistake of thinking that it was only Steve Jobs. He just happened to be more visible than most.

groby_b 10y ago

Meanwhile, I've seen way too much code from people who're good at building things, but not engineering. And lost countless nights to keeping these rickety structures alive long enough that we could fix the most egregious issues. Sure, build something, anything, to show it can be done. THEN MAKE SURE ITS ACTUALLY STABLE. And then realize that building stuff, and understanding how to build it well, both matter.

cagey_vet 10y ago

the first step to curing your problem is realizing you have one.

jluxenberg 10y ago

Slides from @cattsmall keynote mentioned in the article: http://www.slideshare.net/CattSmall/con-the-creative-programmer http://www.slideshare.net/CattSmall/con-the-creative-program...

pedalpete 10y ago

Where you see your greatest weakness, I see your great strength. I'm good at building stuff, but I'm not a great engineer (I'm ok, but others on my team are way better). Not to say I don't have my strengths. I'm good at figuring out what to build and the general architecture of how to get it done quickly and working well. But when it really comes time to scale and scale big, you don't want me coding. You want me looking at the next features etc. etc. If you love getting into the nitty-gritty of high quality beautifully considered easy to work with code, why do you feel you should focus on 'building stuff'? Personally, I think focusing on your strength (not to completely ignore building stuff) can be a huge benefit.

sjg007 10y ago

Meh. It should meet the requirements. And at any rate the next dev to work on your code will declare that it stinks and needs to be refactored at best or completely rewritten.

phantom_package 10y ago

Funny, I'm great at building stuff but I wouldn't consider myself an amazing engineer.

nanodano 10y ago

Another thing I run in to a lot is people saying "I know how to program, but I don't know what to build." There is an amount of creativity involved with programminng. It's like learning how to physically manipulate a guitar and play notes, but saying "I don't know what to play." That happens a lot too, but musicians have the repetoire of other composers to play if they do not want to write their own music (many don't). With programming, recoding something is called reinventing the wheel and that's frowned upon. Ok, sometimes the analogies are forced, but I hope you get it! It's kind of interesting though, because in order to progress we have to build something new, or build on top of what we have, so the technology is forced to evolve. Music can repeat over and over and people don't get tired of it and you could argue pop music is working against the evolution of music. For anyone who hasn't seen the four chord song... https://www.youtube.com/watch?v=oOlDewpCfZQ https://www.youtube.com/watch?v=oOlDewpCfZQ Wait, what we were originally talking about now?

cyberpanther 10y ago

A lot of times as engineers we don't have to build anything. We only have to fix, maintain, or tweak. Or maybe build just a very small piece of something. So it's perfectly OK for most of us to suck at building stuff. But on a team it's important someone fill that role. But most of us shouldn't or it would be chaos.

agentultra 10y ago

Good advice! If we really cared about the systems we create and the effect they have on the world then the language it is programmed in and the implementation of that system would only be one part of the process. The means of effective reasoning about the design of software systems is formal. However it seems to be outside the scope of any introduction to computer science or programming course. To quote Friedrich Bauer: "Software engineering is the part of computer science which is too difficult for the computer scientist."

elishacook 10y ago

I can relate to this. You see it in a lot of domains. I see two concepts that apply: Practice/Performance and Generation/Synthesis. To be a musician you must practice, but you must also perform. These are two different modes. When practicing, the goal is to improve a specific technical skill. You don't concern yourself with expression at all. You will repeat the same passages over and over and many exercises sound really terrible. When you perform, you put your trust in your training and you access an intuitive part of yourself to add feeling and nuance to your playing. In design thinking, it is common to split activities into generation and synthesis. When generating, you recklessly explore possiblities, tossing them out, following blind alleys, making weird connections. Synthesis is the process of evaluating the generated ideas against some framework, such as goals or known models, finding patterns, simplifying and making coherent. We need all of it: practice, performance, generation and synthesis. Experience brings a sense of when each mode is appropriate or needed. Being explicit about which mode you are working in removes the stress from attempting to practice while you are generating or similar dissonant mixes. More concretely, a user-centered process has brought a lot of this mental framework to development for me. Step one is never setting up a test harness, it's understanding the user and their goals, even if the user is yourself. Everything else flows much more easily from this starting point. You can base your decisions on how they will affect the user instead of on "best" practices that may not have the best outcome in your situation. Things like precision, speed, fidelity, automation, complexity, stability, even whether or not to build something--all involve trade offs that affect the user in different ways. You can experiment more freely knowing that you will evaluate your experiments in terms of their utility for the user. The art is in applying this left-brain-right-brain dance to trace a path through all the complexity on behalf of the user.

Jach 10y ago

"Just do it, hack! I approach code like games, rush deep into room, trigger all NPCs, die, after respawn I know where NPCs are." https://twitter.com/bkaradzic/status/494341136245211137 https://twitter.com/bkaradzic/status/494341136245211137

dschiptsov 10y ago

Whether or not one is good is for other people to decide by evaluating one's deeds.

horsecaptin 10y ago

I have the opposite problem. I'm great a building stuff... but I suck at passing job interviews.

thisisadumb 10y ago

i am a good engineer but i am a bad engineer!?

chipsy 10y ago

I like this post because it captures some way in which my perspective has changed over time. Engineering was something I saw as a way to perhaps "cheat" at product problems because if I made a good enough/fast enough/automated enough/generic enough solution, I would be able to iterate on it really fast and so somehow come out ahead of people who went directly towards the simple solution. This mentality was clearly inspired by years of homework being a task that would never go away and that I desperately wanted to get out of my life as fast as possible in the way that consumer products advertise their elimination of household tasks - ergo my goal as a student was to wish I could automate away all aspects of my studies. I would look for any kind of secret trick or forgotten technique that would get me closer to that goal at minimum effort. All the while I would build very little that was finished and get lost in maximizing my use of silver-bullet abstraction. I've eventually come around to flipping this idea on its head, though. If I design not just some kind of product or solution, but a whole process, starting basically with how I want to run my life and then drilling into specific details from there, the technical knowledge stands on more even ground with other forms of knowledge, and with seeing life itself in a more precious sense. With that mindset, good scheduling of every day as an end in itself grows vastly more important, and abstraction-for-its-own-sake falls away: All programming problems start by assuming they are solved first with "code that looks like breadboard wiring" [0] and then working up the abstraction ladder from there. Automating the technical parts of the solution won't guarantee that it's right in any other way, but it will ease the pain of changing the specification. Acknowledging that the problem is messy, that breadboard coding is messy, and that I won't know how to solve everything immediately and cannot depend on a silver bullet, all constitute crucial first steps. Now I always look for really basic groundwork to be laid out early on - typically, transforming the breadboard code into something that uses a new data structure, or generating the code flow from a stack or a list or a tree - and that no shortcut is possible without compromising the ability of a potential future abstraction - that it just takes a lot of layers to get where I want to go. Breadboard code is assumed to be ideal until demonstrated otherwise, while "x in y lines" hype is to be avoided under the assumption that the solution is brittle and over-modeled towards the demo code. I cannot assume that my valuable production code will need x or work in y lines. I don't abstain from adding dependencies, but I will preference towards copy-paste-own when I find a reason to reuse code. [0] http://www.instructables.com/id/How-to-Build-an-8-Bit-Computer/ http://www.instructables.com/id/How-to-Build-an-8-Bit-Comput...

dmarges 10y ago

One thing that really threw me for a loop was back when I started learning about TDD. I tried to apply it to literally everything I coded. This caused a lot of paralysis because I was worried about whether I was testing the right way. Over time I came to a compromise. Basically, if I have a good understanding of the design and what I want to build and I know it is going into Production I use TDD. If I'm not entirely sure what I am building or I'm exploring an idea or spiking/prototyping something then I just write the code with little regard for things like speed or design patterns.