4 ms·

I'm a good programmer. Embrace it! I used to think I'm a bad programmer, and I was. But ever since I'm doing my startup, I'm concentrating on one project in on

by Maro 16y ago

I'm a good programmer. Embrace it! I used to think I'm a bad programmer, and I was. But ever since I'm doing my startup, I'm concentrating on one project in one language, instead of ten different things in 4 different languages. My co-founder and I found and agreed on a practical subset of the language (C++), and we write great code. I'm still a "bad programmer" in the sense that if I wrote Javascript code, it'd not be great, but now I know that the key to success is to concentrate on one thing for a long time --- and actually it's possible to be a "good programmer" if you do that. Okay, I still don't do enough testing, but in our case (distributed DB) the long-term smart solution is to hire a test engineer..

deleted 16y ago
[deleted]
kls 16y ago
You sir get a gold star, The big reason that projects fail is "technology soup", everyone has to get their pet project or technology into the project. It gets worse the bigger the projects get. When you get to the enterprise where the big project are, you get governance and a bunch of design by committee. Where people who are not writing the code, tell the people that are "here is what you are going to use". It is funny but every time I walk into a project that is "fad" programming I see failure. When I walk in a see a bunch of guys heads down, iterating and releasing the most crucial features first, the project always seem to succeed. Maybe the solution is less magic technology dust not more.
- hammerdr 16y ago
  "heads down, iterating and releasing the most crucial features first" That's the key. The "number" of technologies involved is moot. Every piece of software is build upon thousands of layers of technology. Adding one or more ingredients to the soup doesn't necessarily ruin it. Often the simplest way to solve a problem is to duct-tape two different items from different technology stacks just well enough that it works for you. In that simplest case, you may be duct-taping 2 technologies together with a 3rd.
  - kls 16y ago
    I disagree somewhat, one of the reason the web is a battle ground of corpses, that where once projects is due to the fact that it became a convoluted mess. The bar to be proficient required HTML, CSS, XML, (JSP, ASP, PHP pick one) generally some frameworks (taglibs, struts, tiles), SQL, Web servers, applications servers, Database servers, CMS servers that double as a bad application server, the list sprawls out from here. Developers had to master all of this just to put a page together. Technology soup can bloat to the point where it is unmaintainable. When you get into the enterprise you can add MQ, LDAP, SAP, Peoplesoft and a slew of others, that require integration. SOA and ESB's are doing a lot to clean it up and give a single implementation technology but it is still a mess. Jaguar once had the distinction of being the automobile with the most moving parts, they also had the distinction of being one of the most unreliable vehicles. Technology for technologies sake is always a project killer. I have seen it too many times. When I take over a troubled project (one of my specializations is troubled project rescue) one of my first efforts is to reduce the amount of technology load the project carries. That coupled with a focus on MVP saves a good deal of projects.

by Maro 16y ago

deleted 16y ago

[deleted]

kls 16y ago

You sir get a gold star, The big reason that projects fail is "technology soup", everyone has to get their pet project or technology into the project. It gets worse the bigger the projects get. When you get to the enterprise where the big project are, you get governance and a bunch of design by committee. Where people who are not writing the code, tell the people that are "here is what you are going to use". It is funny but every time I walk into a project that is "fad" programming I see failure. When I walk in a see a bunch of guys heads down, iterating and releasing the most crucial features first, the project always seem to succeed. Maybe the solution is less magic technology dust not more.

hammerdr 16y ago
"heads down, iterating and releasing the most crucial features first" That's the key. The "number" of technologies involved is moot. Every piece of software is build upon thousands of layers of technology. Adding one or more ingredients to the soup doesn't necessarily ruin it. Often the simplest way to solve a problem is to duct-tape two different items from different technology stacks just well enough that it works for you. In that simplest case, you may be duct-taping 2 technologies together with a 3rd.
- kls 16y ago
  I disagree somewhat, one of the reason the web is a battle ground of corpses, that where once projects is due to the fact that it became a convoluted mess. The bar to be proficient required HTML, CSS, XML, (JSP, ASP, PHP pick one) generally some frameworks (taglibs, struts, tiles), SQL, Web servers, applications servers, Database servers, CMS servers that double as a bad application server, the list sprawls out from here. Developers had to master all of this just to put a page together. Technology soup can bloat to the point where it is unmaintainable. When you get into the enterprise you can add MQ, LDAP, SAP, Peoplesoft and a slew of others, that require integration. SOA and ESB's are doing a lot to clean it up and give a single implementation technology but it is still a mess. Jaguar once had the distinction of being the automobile with the most moving parts, they also had the distinction of being one of the most unreliable vehicles. Technology for technologies sake is always a project killer. I have seen it too many times. When I take over a troubled project (one of my specializations is troubled project rescue) one of my first efforts is to reduce the amount of technology load the project carries. That coupled with a focus on MVP saves a good deal of projects.