|
You can work 80 hour weeks. Or more.
Friend of mine wanted that. I recommended against it. At one place he would come in at 3am and code until about 11am, then act as the CTO until about 6pm. He generally also coded on the weekends. Fortunately the wife seemed to be ok with him being out of the house all the time.
|
|
|
|
|
Pete sits in the corner and waves hand.
|
|
|
|
|
Sorry buddy, I forgot to give you the obligatory shoutout.
It's because my Uber Eats order was messed up. That's my story and I'm sticking to it.
Jeremy Falcon
|
|
|
|
|
Yes, I hired someone just last month, with my own money out of my own pocket! 
If this guy messes up, or even gets sick through no fault of his own, I am screwed.
Why, what do you want to know?
|
|
|
|
|
Sander Rossel wrote: I am screwed
Good times. Good times. 
Sander Rossel wrote: Why, what do you want to know?
Nothing in particular. Just fishing around to see which peeps I have more in common with than not. Trying to get smarter with my online interactions.... trying to at least.
Hope your venture goes great btw.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Just fishing around to see which peeps I have more in common with than not.
So do we have more or less in common?
Jeremy Falcon wrote: Hope your venture goes great btw.
Thanks! So far so good, survived COVID and everything 
|
|
|
|
|
Sander Rossel wrote: So do we have more or less in common?
Dunno yet. I think we do have some stuff in common, but it's also hard to tell in passing and online ya know. I do know that I tend to have more empathy for the PHB than most coders on here that never hired anymore and that can lead to interesting chats for sure. Like, I'm sure how you've seen some devs just want to be left alone and their silo, which works on a junior and maybe mid-level on smaller teams. But that doesn't work for senior level and so on. From the employer's perspective the dev never brings up issues, but from the dev's perspective they're always worried about timelines (they commit to) and coding. Just nice to chat about stuff like that with peeps who've been around the block.
Sander Rossel wrote: Thanks! So far so good, survived COVID and everything
Noice.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Like, I'm sure how you've seen some devs just want to be left alone and their silo, which works on a junior and maybe mid-level on smaller teams. But that doesn't work for senior level and so on.
I'd say that works in bigger companies if they do specialised work.
I'm in a small team now, with two programmers and sometimes a third for some additional expertise.
We can't afford a lone wolf right now.
It would mess up the team dynamic and work flow too much.
I simply don't have the work where someone can work alone for longer periods of time.
Programming complex systems with more than one person should always be a team effort, not a two-(or-more)-people-apart effort.
I'm keeping my employee informed, so he knows about upcoming deadlines and why they're important.
Also, if a deadline is not important I tell him too.
No sweat if an arbitrary deadline is a few days late.
I'm an employer, but also still very much a programmer 
|
|
|
|
|
Sander Rossel wrote: We can't afford a lone wolf right now.
100% agree, except I'd add that the lone wolf doesn't really work to well even in a larger company. Even in a larger company, I still try to break down teams to be a max of no more than 10 people total... including QA/SDETs. So, you'd still get the small team dynamic. But, I was trying to be benign earlier because for me, CP is just a place to argue with people who have no experience in the subject they are arguing about. And well, that gets old. But totally agree with this.
Sander Rossel wrote: Programming complex systems with more than one person should always be a team effort, not a two-(or-more)-people-apart effort.
Preaching to the choir, buddy. 
Sander Rossel wrote: why they're important.
That's a sign of good leadership. Creative people are rebellious by nature (we can make something better, new, etc.) but in my experience, if you let a dev know the why something is they'll usually accept it rather than just say "because I said so." Well, assuming they're good devs and assuming the why isn't totally off the wall.
Sander Rossel wrote: I'm an employer, but also still very much a programmer
Don't ever lose that man. Steve Jobs (or anyone who's intelligent) believed the best managers (which an employer is to start with) started off as a dev. Not one of the clowns who's in it for the money or to just tell other people what to do. Programmers inherently have more respect for someone being one of their own. They may not always say it for fear of getting fired, etc. But, it's true.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: CP The internet is just a place to argue with people who have no experience in the subject they are arguing about.
FTFY
We seem to agree on all accounts though, so no need to argue there.
A pretty rare phenomenon on the internet 
|
|
|
|
|
Sander Rossel wrote: A pretty rare phenomenon on the internet
Jeremy Falcon
|
|
|
|
|
Swindle discharge charged tradition (10)
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Nice one!
Swindle CON
discharge VENT
charged ION
tradition
CONVENTION
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I originally had
Sisters place charged for assembly
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
That was good too! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I ran into an issue recently on a professional embedded project, and that was this:
In translating the flow diagrams to code, there were so many conditions around state changes and such that my options were to either abstract the flow with some sort of generalized framework, or cook some spaghetti code.
I chose the latter.
Why? Simple. The actual effort if anything would be about equal, or favor the spaghetti approach.
More importantly, progress remains visible with the spaghetti approach rather than the abstract flow framework which requires a lot of up front design and work without progress visible to the client.
Finally, this is embedded code, where a rewrite is maybe a grand or two $USD, on the outside, assuming not a lot of reuse. It would cost at least half that to develop a simple framework, which might make things more maintainable, but questionable in terms of how effortlessly one can make changes (whereas maintainability is more about stepping away for a month and being able to pick it up again, mostly - or someone else picking up your code). It's all a matter of robbing peter to pay paul.
The bottom line here is that while we may chase perfect code, and "best practices" that's not always the most effective technique for keeping the lights on.
Flame away.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I would have to agree. Having worked with Fortran (spaghetti land), "spaghetti code" was often quite efficient. We tried to reduce it's complexity but it just got slower. At least it was not a large piece of code and it was commented. It's still running somewhere. Long live Fortran. Yikes.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I understand and mostly agree with your reasoning, but writing spaghetti code feels dirty, somehow.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I feel the same way, and when I was less experienced I used to - if not outright refuse to write code like this, I would make excuses to myself to get away from it at least.
Experience is an expensive teacher, but it taught me (among other things) that successful projects virtually never rest on great code. They rest on effective development practices, and those are more bespoke the smaller the team is.
Time is money, and money is king. That's what makes me feel dirty - acknowledging that cold reality.
If one is not something of a bean counter when one plans out their coding one could do better - by the clients.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I have the impression that OP interchanges 2 things: purpose built single use code, and code with horrible control flow and global data access.
I've written code for running on DSPs, on the bare hardware, and everything was purpose coded with a thin hardware abstraction library I made. In my case I had only 16K program memory and 2K RAM. hardware limits aside, when you are programming close to bare metal, it starts to be less and less useful to implement generic frameworks.
|
|
|
|
|
In my case, I opted for making the code flow with the rather complicated flowcharts I was provided.
Rather than abstract everything to make it cleaner, because of the reasons I stated before, I decided that at the very least the code could follow the documentation, however messy. At least the documents and the code match somewhat. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
I have programmed a lot of PLCs and while I had a lot of more resources in hardware than you, my coding options were way smaller.
Using JMP to control the flow of the program (IF-Else, Calls, partial returns...) was a must.
There were no other options.
But as you say, having to program like this, it doesn't mean that the code flow has to be ugly, weird or confusing.
The different between clean or crappy programs depends mostly on the person programing it, not on the methodic or the language.
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.
|
|
|
|
|
I agree, Bruno. If you need to build a shed, you don't use sky scrapper blue prints.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
If it feels dirty, it's because it is. Trust your instincts.
Jeremy Falcon
|
|
|
|
|
Daniel Pfeffer wrote: writing spaghetti code feels dirty, somehow.
Well, spaghetti sauce does stain...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
