Giving up programming
-
Put a big sign on the wall: A PROCESS SHOULD ONLY BE CONSIDERED IF: 1: It demonstrably improves products or services from the customer perspective. 2: It demonstrably improves the efficiency of product/service implementation without having a negative effect on point 1. 3: It demonstrably makes the job easier for those implementing the product/service, without having a negative effect on points 1 or 2. All too many poor and/or inappropriate processes are put in place because they're either fashionable or they appeal to one or more people personally. If a process, no matter how "in" it is or how appealing it is to your or anyone else's tastes, does not *demonstrably* meet the requirements above, it should be replaced with processes that do. And keep pounding the word "demonstrably". If someone wants a new process, he has to demonstrate the effects it will have on the company, including all the cons (make sure that any discussions go straight to seeking out the cons, rather than bathing in the glory of the pros).
I wanna be a eunuchs developer! Pass me a bread knife!
:thumbsup: And far, far too many groups put the customer perspective last, if they consider it at all.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
:thumbsup: And far, far too many groups put the customer perspective last, if they consider it at all.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Ladies and Gentlemen, I give you "Usability Driven Development" - - If the ops don't understand, it ain't n't usable! - If the devs don't understand, it ain't n't usable! - If the users don't understand, it ain't n't usable! - If the support don't understand, it ain't n't usable! - If the managers don't understand, it ain't n't usable! So make it usable!
-
So change it: come up with a unified solution - gawd knows we need it. Now there is a development task for you! :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
OriginalGriff wrote:
So change it: come up with a unified solution
I really like this positive attitude and goal-oriented re-framing of the problem. This is truly Engineering Life. +100 Life Points* to you. May you live long an prosper, Gandalf. 1 Life Point = 32 heart points 1 heart point = 6.72 happy points 1 happy point = 3 cups of coffee 1 cup of coffee = warm lively goodness In normal play, 100 Life Points would take 7.2 game years**#** # 7.2 Game Years = 37.38 Real Life Years. That means you have just gained an extra 37.38 Real Life Years on your life if you choose to redeem them. :)
-
I think I have had enough. I still enjoy programming but there seems to be very little of it around any more. I spend my time fighting with the tools rather than working on the solution. Deployment is an utter farce. Source control is hideous. Web Services are appalling hacks. Web development is a massive step backwards dragging all manner of shonky technologies and libraries together.
This is what happens when non-developers/programmers, call the shots for too long a period of time. Half the tools that we are forced to use, we really should not be using. People use technology just because it is new, not because it is correct. Also, most of us (I want to say all) are forced to meet unrealistic deadlines for production releases. Haste makes waste, on every level, every time. I have never worked on a project in my 15+ year career that has not ended in failure of some sort, if we went too fast.
-
What tools are you using? I've been using Microsoft Visual tools for 20 odd years and they've never been better. Sure, we all miss Visual SourceSafe and the web is just an abomination, but there's plenty of scope for *proper* programming still.
Regards, Rob Philpott.
-
I have no complaints about the programming language environment in VS2010/12 - they are great. I loathe any kind of source control - I have never had any actual cause to use it but spend a lot of time fighting it
RugbyLeague wrote:
I loathe any kind of source control
Uh oh. If you work at a large place you'll get hit over the head with the Source Control Hammer. They just tell you that you must use it. And many source control packages are confusing and annoying, until you learn the point of how they help you. But Source Control is a Real Programmer's Best Friend. Why do I say that? There are many benefits to using Source Control: Branching -- changing code without damaging your original trunk code. Then if you don't want to do the change, you just drop the branch, nothing lost. Tagging -- Oh man, there are so many companies that cannot simply check out the exact version of source that was used to build a particular version that is in production. That's because they didn't Tag. With Source Control you can Tag an exact version, then later when someone says there is a bug in version 3.01, you can go and get that exact source and attempt to reproduce the error even though you are 5 versions past it. It is amazing. Diffing -- I leave on Friday and by Monday I open source files and wonder "who's been hacking around in here?" Answer: "It was me." I can see all of that because I can do diffs on the code from so many angles that I can tell exactly which source files were changed and by who. It is fantastic. You must see the tools as something working for you and attempt to learn how they work for you to get all of this. I used to hate source control too, but if you'll see it as a programmer's helper you will see your life can be so much better. Good luck.
-
I think I have had enough. I still enjoy programming but there seems to be very little of it around any more. I spend my time fighting with the tools rather than working on the solution. Deployment is an utter farce. Source control is hideous. Web Services are appalling hacks. Web development is a massive step backwards dragging all manner of shonky technologies and libraries together.
-
RugbyLeague wrote:
I loathe any kind of source control
Uh oh. If you work at a large place you'll get hit over the head with the Source Control Hammer. They just tell you that you must use it. And many source control packages are confusing and annoying, until you learn the point of how they help you. But Source Control is a Real Programmer's Best Friend. Why do I say that? There are many benefits to using Source Control: Branching -- changing code without damaging your original trunk code. Then if you don't want to do the change, you just drop the branch, nothing lost. Tagging -- Oh man, there are so many companies that cannot simply check out the exact version of source that was used to build a particular version that is in production. That's because they didn't Tag. With Source Control you can Tag an exact version, then later when someone says there is a bug in version 3.01, you can go and get that exact source and attempt to reproduce the error even though you are 5 versions past it. It is amazing. Diffing -- I leave on Friday and by Monday I open source files and wonder "who's been hacking around in here?" Answer: "It was me." I can see all of that because I can do diffs on the code from so many angles that I can tell exactly which source files were changed and by who. It is fantastic. You must see the tools as something working for you and attempt to learn how they work for you to get all of this. I used to hate source control too, but if you'll see it as a programmer's helper you will see your life can be so much better. Good luck.
I have been trying with source control and I kind of understand why some people like it. Personally I have never had any benefit from it but lots and lots and lots of trouble. Maybe because I don't understand how to use it.
-
I have one. I built my own programming language, it's own IDE, and my own database engine and query GUI (winning several industry awards) Unfortunately it all requires very little maintenance and deployment takes seconds. So I am on other projects now - which is mostly about fighting with the tools
RugbyLeague wrote:
I have one. I built my own programming language, it's own IDE, and my own database engine and query GUI
Impressive. Sounds a lot like what I did a few years ago as well.
RugbyLeague wrote:
Unfortunately it all requires very little maintenance and deployment takes seconds.
Exactly. The funny thing is, it's actually hard to sell the solution because it's so not the Microsoft way. Annoying. Marc
-
I have no complaints about the programming language environment in VS2010/12 - they are great. I loathe any kind of source control - I have never had any actual cause to use it but spend a lot of time fighting it
RugbyLeague wrote:
I loathe any kind of source control - I have never had any actual cause to use it
I thought that, too, until I had to uninstall/reinstall a product and discovered the app I had been working on was deleted in the process. I know, why didn't I have it backed up? Because the laptop was on a corporate image and I had limited control over what I could do. I was able to get a working copy of the DLL, reverse it and rebuild the code... but it was painful. Now, I use Visual SourceSafe; yes, we are still on VSS.. for now... Make a change, check it in. If I decide I don't like it, check out a previous version.
-
I think I have had enough. I still enjoy programming but there seems to be very little of it around any more. I spend my time fighting with the tools rather than working on the solution. Deployment is an utter farce. Source control is hideous. Web Services are appalling hacks. Web development is a massive step backwards dragging all manner of shonky technologies and libraries together.
RugbyLeague wrote:
Deployment is an utter farce. Source control is hideous. Web Services are appalling hacks. Web development is a massive step backwards dragging all manner of shonky technologies and libraries together.
When it comes to non-Microsoft products, I completely agree. Just getting all the pieces working for a relatively simple Ruby on Rails website deployed (dealing with version changes in Ubuntu, Apache, Passenger, not to mention Rails), all of which require editing config files, changing source code or loading gems that let you still use "legacy" code (especially in the constantly changing Rails ORM) is enough to get me running back to Windows, C#, etc. And don't even get me started on the insane state of web development with the myriad of [the next awesome framework]-js "stuff." The thing that annoys and saddens me about the state of affairs is the old adage, point a finger at someone and you have four fingers pointing back at you. Because at the end of the day, we have only ourselves to blame. This is the other edge of the open source sword that nobody seems to be talking about -- that anyone can create a framework. While I rant occasionally about Microsoft, there is at least some sense of direction and a certain degree of cohesiveness and product integration. Sure, there's quite a few dead ends (Silverlight, WPF, Object Spaces, etc.) but when, for example, I wrote an article on the history of C#, I came to realize that there actually does seem to be a master plan, and a good one, at work. I would say the same thing of Windows itself, even though I loathe W8. Conversely, the OS community often seems like a monster flailing in its own excrement, hoping the shit will stick somewhere, with only an occasional diamond being dredged up, but unfortunately still covered in shit. Marc
-
RugbyLeague wrote:
I loathe any kind of source control
Uh oh. If you work at a large place you'll get hit over the head with the Source Control Hammer. They just tell you that you must use it. And many source control packages are confusing and annoying, until you learn the point of how they help you. But Source Control is a Real Programmer's Best Friend. Why do I say that? There are many benefits to using Source Control: Branching -- changing code without damaging your original trunk code. Then if you don't want to do the change, you just drop the branch, nothing lost. Tagging -- Oh man, there are so many companies that cannot simply check out the exact version of source that was used to build a particular version that is in production. That's because they didn't Tag. With Source Control you can Tag an exact version, then later when someone says there is a bug in version 3.01, you can go and get that exact source and attempt to reproduce the error even though you are 5 versions past it. It is amazing. Diffing -- I leave on Friday and by Monday I open source files and wonder "who's been hacking around in here?" Answer: "It was me." I can see all of that because I can do diffs on the code from so many angles that I can tell exactly which source files were changed and by who. It is fantastic. You must see the tools as something working for you and attempt to learn how they work for you to get all of this. I used to hate source control too, but if you'll see it as a programmer's helper you will see your life can be so much better. Good luck.
My source control is just to make a zip-backup with format: Projekt_name - Timestamp - Brief description of the higlights made that day With it I have the "Branching" and "Tagging" functionality you describe. The only one missing is "Diffing" but, since in the PLC-World it is very uncommon that more than a person works in the very same programm, I don't really need it. The only one making changes it's me.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Ladies and Gentlemen, I give you "Usability Driven Development" - - If the ops don't understand, it ain't n't usable! - If the devs don't understand, it ain't n't usable! - If the users don't understand, it ain't n't usable! - If the support don't understand, it ain't n't usable! - If the managers don't understand, it ain't n't usable! So make it usable!
Nagy Vilmos wrote:
- If the managers don't understand, it ain't n't usable!
Then 99% of my code is not usable ;P
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Put a big sign on the wall: A PROCESS SHOULD ONLY BE CONSIDERED IF: 1: It demonstrably improves products or services from the customer perspective. 2: It demonstrably improves the efficiency of product/service implementation without having a negative effect on point 1. 3: It demonstrably makes the job easier for those implementing the product/service, without having a negative effect on points 1 or 2. All too many poor and/or inappropriate processes are put in place because they're either fashionable or they appeal to one or more people personally. If a process, no matter how "in" it is or how appealing it is to your or anyone else's tastes, does not *demonstrably* meet the requirements above, it should be replaced with processes that do. And keep pounding the word "demonstrably". If someone wants a new process, he has to demonstrate the effects it will have on the company, including all the cons (make sure that any discussions go straight to seeking out the cons, rather than bathing in the glory of the pros).
I wanna be a eunuchs developer! Pass me a bread knife!
-
Nagy Vilmos wrote:
- If the managers don't understand, it ain't n't usable!
Then 99% of my code is not usable ;P
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
You fell straight into the trap. What does the manager need to understand? He [probably] won't understand the code, nor does he need to. He will need to understand what it does, how it can be used, maybe who will buy it. THAT is his understanding. Now if you look at each stakeholder, think about what they need to understand. The code may be elegant and simple but the UI is cluttered - FAIL for the user. A beautiful and simple UX with an unmaintainable heap behind - FAIL for the devs. Think about what people want, not just what you want.
-
I think I have had enough. I still enjoy programming but there seems to be very little of it around any more. I spend my time fighting with the tools rather than working on the solution. Deployment is an utter farce. Source control is hideous. Web Services are appalling hacks. Web development is a massive step backwards dragging all manner of shonky technologies and libraries together.
Thank goodness, I thought it was just me . I spend longer thinking about other peoples frameworks than it would have taken me to write half the things from scratch .
-
I have no complaints about the programming language environment in VS2010/12 - they are great. I loathe any kind of source control - I have never had any actual cause to use it but spend a lot of time fighting it
Dude, Source control is your friend. If you don't understand the Source Control they are using try try try, But seriously take the time to check out other Source Control processes. I have been forced to use GIT, TFS(VSS) in my job. But for my home projects and my home machine I use TortouseHG/ http://tortoisehg.bitbucket.org/[^] It just works and it is simple to use and it interfaces with VS Ruby ETC.... Love it. Seriously Source Control makes you a better programmer because you no longer have to worry about what changes I made or where this rabbit hole I am in is going. It gives you and quick way to get back to the beginning and start down another rabbit hole and takes care of all the overhead. Never mind working with a team. This is just my own mind going down the various trails to see where I might end up.
To err is human to really mess up you need a computer
-
Thank goodness, I thought it was just me . I spend longer thinking about other peoples frameworks than it would have taken me to write half the things from scratch .
Don't get me started on frameworks
-
Dude, Source control is your friend. If you don't understand the Source Control they are using try try try, But seriously take the time to check out other Source Control processes. I have been forced to use GIT, TFS(VSS) in my job. But for my home projects and my home machine I use TortouseHG/ http://tortoisehg.bitbucket.org/[^] It just works and it is simple to use and it interfaces with VS Ruby ETC.... Love it. Seriously Source Control makes you a better programmer because you no longer have to worry about what changes I made or where this rabbit hole I am in is going. It gives you and quick way to get back to the beginning and start down another rabbit hole and takes care of all the overhead. Never mind working with a team. This is just my own mind going down the various trails to see where I might end up.
To err is human to really mess up you need a computer
I have to use TFS Previously I would just zip up my dev folder and park it in a rolling folder in the server so it would be backed up. If I found myself going down the wrong path I would just restore the project from the zip file. Live releases would get their own backed up zip file. Easy peasy, lemon squeezy
-
You fell straight into the trap. What does the manager need to understand? He [probably] won't understand the code, nor does he need to. He will need to understand what it does, how it can be used, maybe who will buy it. THAT is his understanding. Now if you look at each stakeholder, think about what they need to understand. The code may be elegant and simple but the UI is cluttered - FAIL for the user. A beautiful and simple UX with an unmaintainable heap behind - FAIL for the devs. Think about what people want, not just what you want.
Nagy Vilmos wrote:
Now if you look at each stakeholder, think about what they need to understand. The code may be elegant and simple but the UI is cluttered - FAIL for the user. A beautiful and simple UX with an unmaintainable heap behind - FAIL for the devs.
That is what I always try. I usually ask the future users and their "seniors" or maintenance guys or ingenieurs when developing the concept, to make it as close as I can to their "wills" or needs. Then I program the code in such a way, it is self-explaining. Not only for other people, but for me if I have to get back there somewhen in the future, when I don't remember anymore what I thought when programming it. My team leader always aks... does what it has to do? Does it with realiability and without blockades? Did you finish in time or get more money for the "extras"? If yes to all... then he is happy and let me manage myself on my own.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
