4 ms·

Very true for me. Computers were a tool to build programs. Then I spent time researching programming languages and making frameworks (in summary: building abstr

Very true for me. Computers were a tool to build programs. Then I spent time researching programming languages and making frameworks (in summary: building abstractions). Now I'm back to building non-abstract things again. I wonder if it's going to repeat itself or if it'll stay this way.

garethsprice 15y ago
Exact same path for me. Now I'm hyper-pragmatic and feel like I've plateaued somewhat as a developer - I'm producing systems that work well and fulfill clients' needs but I'm finding building them isn't the exciting challenge it once was. Where now?
- quanticle 15y ago
  Programming contests [1] can a fun and challenging diversion. 1. http://aichallenge.org/ http://aichallenge.org/
- olliesaunders 15y ago
  Assuming you mean you’re writing more concrete (less abstract) code as a means of productivity, if you want to go back to writing abstractions, you might need to go into academia. That seems to be the only place where the necessary years of thought go into creating abstractions that actually stand up to the problems they intend to solve. I’d cite Haskell and GraphiViz as examples of this. Personally I’m also interested in deductive databases and ontology but, on the whole, those are too ambitious even for academia these days, which I think is a shame because to me logically organizing information is probably one of the most important problems in IT since the web was created.
  - pnathan 15y ago
    Deductive databases - prologish systems? It seems that a good prologish system could solve large classes of "business rules" problems pretty easily.
    - olliesaunders 15y ago
      Prolog is great for being a really early logic programming language but compared to modern languages it just isn’t very clever or powerful. If you’re interested in logic programming have a look at Mercury: http://news.ycombinator.com/item?id=2959167 http://news.ycombinator.com/item?id=2959167
- biot 15y ago
  I find I'm in a similar mindset. What I've found is that once I stop learning, things become boring. Yes, I know I can take that interface, hook it up to this database, and with a bit of logic glue make a wonderful app come alive. The only challenge in that kind of work where you already know how to do every piece is overcoming the sheer boredom from going through the motions. So what I think is the solution is to go meta. Step back and ask why you're having to write the same code to pump out the same kinds of apps. What is the commonality between all the various apps you're writing? Now solve that problem. The ultimate iteration of this, if done successfully, is a system that takes a design plus a formal specification of an app's functionality and automagically makes it work. Now you're working at a higher level of abstraction. I don't yet know what happens when you get bored of that. Perhaps by then you'll have developed your own AI.
  - abp 15y ago
    Perhaps by then you'll have developed your own AI. No, I think you're maintaining the abstractions you built before that point. Look at all the frameworks that get developed for many years before they're abandoned.
rjd 15y ago
I remember years ago having a senior developer say to me "don't use software patterns they will only make things complicated, you'll regret it in the long run." I scoffed at him, sat down with my books and learned al sorts of things. After say 5 years I understand what he was saying to me know. Patterns are patterns, they implement themselves when you need them. All you need to know is how not to do it badly. You shouldn't be trying to implement patterns if you don't need them. I know its a high horse position, because you need to go through a phase of using them to understand why they aren't a miracle cure. o I find the the growth/education of a programmer some what similar to the articles notion. For reference any younger dev out there that looks at the work senior devs and thinks to themselves "why are they senior? there work is obviously rubbish", you'll probably end up that senior dev one day. In my experience most senior devs have been like you... perfectionists, aborbsed with the latest greatest etc... and you learn over time all that really matters is delivering on time, code management, and getting burnt by the latest and greatest really sucks. So you slowly stop writing over engineered code. That often means doing things a basic way, so people in the team aren't left behind that don't understand, understanding your code isn't that critical... whats critical is finishing on time, that optimisation is the last thing you do because it takes to long and you really don't know if what you are writing deserves so much attention (i.e. if it takes off revisit the code, if a choke point starts appearing then optimise). Basically don't waste time on problems which don't exist, don't create stress for yourself/team/management by over engineering solutions. Next time you wonder why a senior dev seems to be hopeless ask them why they choose to deliver a solution like a beginner and maybe you'll learn something invaluable ;)
- pnathan 15y ago
  Patterns are patterns, they implement themselves when you need them. That has been my understanding. I consider that the only practical reason to review design patterns is so you can communicate the style of code to another. After a while as you program you look through the code and see the needed meaning, shaping the code to conform to the meaning better.
  - rjd 15y ago
    Yep I know exactly what you mean. What I find kind of interesting is I would feel nervous having myself from 5 years ago in my team today. That guy was pretty damned sharp, worked long hours, researched implemented push boundaries, and delivered some stuff I'm still proud of. But he had something to prove, he put meaning into things that didn't want or need meaning. Over engineered everything. But a calmer/mature more strategic me says I don't need mavericks on business automation software. I'd be watching me like a hawk, because I made mistakes, big ones from time to time (my favourite was a system failure costing €50,000 in lost revenue... all my fault, I was literally told to clear my desk and was marched out the door). You need those mavericks to push boundaries, its fun to be one, but boy its disconcerting when you have one in your team and all you need t do is deliver is a CRUD application.

garethsprice 15y ago

Exact same path for me. Now I'm hyper-pragmatic and feel like I've plateaued somewhat as a developer - I'm producing systems that work well and fulfill clients' needs but I'm finding building them isn't the exciting challenge it once was. Where now?

quanticle 15y ago
Programming contests [1] can a fun and challenging diversion. 1. http://aichallenge.org/ http://aichallenge.org/
olliesaunders 15y ago
Assuming you mean you’re writing more concrete (less abstract) code as a means of productivity, if you want to go back to writing abstractions, you might need to go into academia. That seems to be the only place where the necessary years of thought go into creating abstractions that actually stand up to the problems they intend to solve. I’d cite Haskell and GraphiViz as examples of this. Personally I’m also interested in deductive databases and ontology but, on the whole, those are too ambitious even for academia these days, which I think is a shame because to me logically organizing information is probably one of the most important problems in IT since the web was created.
- pnathan 15y ago
  Deductive databases - prologish systems? It seems that a good prologish system could solve large classes of "business rules" problems pretty easily.
  - olliesaunders 15y ago
    Prolog is great for being a really early logic programming language but compared to modern languages it just isn’t very clever or powerful. If you’re interested in logic programming have a look at Mercury: http://news.ycombinator.com/item?id=2959167 http://news.ycombinator.com/item?id=2959167
biot 15y ago
I find I'm in a similar mindset. What I've found is that once I stop learning, things become boring. Yes, I know I can take that interface, hook it up to this database, and with a bit of logic glue make a wonderful app come alive. The only challenge in that kind of work where you already know how to do every piece is overcoming the sheer boredom from going through the motions. So what I think is the solution is to go meta. Step back and ask why you're having to write the same code to pump out the same kinds of apps. What is the commonality between all the various apps you're writing? Now solve that problem. The ultimate iteration of this, if done successfully, is a system that takes a design plus a formal specification of an app's functionality and automagically makes it work. Now you're working at a higher level of abstraction. I don't yet know what happens when you get bored of that. Perhaps by then you'll have developed your own AI.
- abp 15y ago
  Perhaps by then you'll have developed your own AI. No, I think you're maintaining the abstractions you built before that point. Look at all the frameworks that get developed for many years before they're abandoned.

rjd 15y ago

I remember years ago having a senior developer say to me "don't use software patterns they will only make things complicated, you'll regret it in the long run." I scoffed at him, sat down with my books and learned al sorts of things. After say 5 years I understand what he was saying to me know. Patterns are patterns, they implement themselves when you need them. All you need to know is how not to do it badly. You shouldn't be trying to implement patterns if you don't need them. I know its a high horse position, because you need to go through a phase of using them to understand why they aren't a miracle cure. o I find the the growth/education of a programmer some what similar to the articles notion. For reference any younger dev out there that looks at the work senior devs and thinks to themselves "why are they senior? there work is obviously rubbish", you'll probably end up that senior dev one day. In my experience most senior devs have been like you... perfectionists, aborbsed with the latest greatest etc... and you learn over time all that really matters is delivering on time, code management, and getting burnt by the latest and greatest really sucks. So you slowly stop writing over engineered code. That often means doing things a basic way, so people in the team aren't left behind that don't understand, understanding your code isn't that critical... whats critical is finishing on time, that optimisation is the last thing you do because it takes to long and you really don't know if what you are writing deserves so much attention (i.e. if it takes off revisit the code, if a choke point starts appearing then optimise). Basically don't waste time on problems which don't exist, don't create stress for yourself/team/management by over engineering solutions. Next time you wonder why a senior dev seems to be hopeless ask them why they choose to deliver a solution like a beginner and maybe you'll learn something invaluable ;)

pnathan 15y ago
Patterns are patterns, they implement themselves when you need them. That has been my understanding. I consider that the only practical reason to review design patterns is so you can communicate the style of code to another. After a while as you program you look through the code and see the needed meaning, shaping the code to conform to the meaning better.
- rjd 15y ago
  Yep I know exactly what you mean. What I find kind of interesting is I would feel nervous having myself from 5 years ago in my team today. That guy was pretty damned sharp, worked long hours, researched implemented push boundaries, and delivered some stuff I'm still proud of. But he had something to prove, he put meaning into things that didn't want or need meaning. Over engineered everything. But a calmer/mature more strategic me says I don't need mavericks on business automation software. I'd be watching me like a hawk, because I made mistakes, big ones from time to time (my favourite was a system failure costing €50,000 in lost revenue... all my fault, I was literally told to clear my desk and was marched out the door). You need those mavericks to push boundaries, its fun to be one, but boy its disconcerting when you have one in your team and all you need t do is deliver is a CRUD application.