|
Just started season 2. You only have so much time to devote to TV so need to pick what you watch carefully. This is on my list as it is darkly entertaining. Note that the director spends a lot of money making sure that the code you see on screen is as real as it can be.
|
|
|
|
|
It's excellent.
I've seen all of season one.
The "hacking" is actually a little more realistic than you usually see in Hollywood, but don't take it too seriously. The characters and the story are great though.
|
|
|
|
|
I've only watched the first 2 episodes from season 1. I want to like it, but not sure yet. Giving it a few more episodes. BTW, if you haven't caught it yet, check out first season of "Halt and Catch Fire" ( on AMC, I think); other seasons not as good, IMO.
|
|
|
|
|
I watched two episodes, and it was already getting too self-absorbed and stupid, for me, so I stopped there.
We don't all have the same tastes, though -- e.g. some people have no taste, so they like self-absorbed, stupid shows.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Watched season 1 long ago - really good
season 2 - watched 1.5 episodes so far. Not that impressed. Getting bit convoluted or I need to re-watch highlights of previous season.
Zen and the art of software maintenance : rm -rf *
Maths is like love : a simple idea but it can get complicated.
|
|
|
|
|
I'm 3 episodes in and the thing I've noticed the most is that whoever put the audio effects and sound track in has really done a good job. I think this makes it more than the script.
|
|
|
|
|
I'm actually thinking of writing an article entitled "Software Engineering is Dead", but I want to ask y'all, when you think of software engineering, how do you practice it in, well, practical terms?
Anything from doing detail design analysis, prototypes (that don't turn into production code), design patterns, high level architectures like messaging, pub/sub, modular, service oriented, async, etc., all are fair game for what, in practice, "engineering" looks like. (Note how I snuck the idea of "high level architecture" into the idea of "engineering".)
I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job?
Marc
|
|
|
|
|
Don't ask me, I am a Klingon Developer.
Someone, however thinks it is 'anything helpful to cope with the mess'. So, above all, well documented (or at least heavily commented) API, then, yes, prototyping and testing, and possibly design for testing.
|
|
|
|
|
CPallini wrote: I am a Klingon Developer
You haven't programmed until you've written something in Klingon Basic! 
Marc
|
|
|
|
|
I personally don't think an app can be properly engineered in an agile environment.
I'm self taught (aka, the Outlaw Programmer School of Software Development).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: Outlaw Programmer School of Software Development
Is that the "Code first and ask questions later" school?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Precisely. Give me the specs, and go away. I'll let you know when it's finished.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Tell me the problem you want to solve and then leave me alone to do the job. Precisely.
Software Zen: delete this;
|
|
|
|
|
John Simmons / outlaw programmer wrote: I personally don't think an app can be properly engineered in an agile environment.
Now that opens a door, actually a chasm, which would make for an interesting discussion. Care to elaborate? 
Marc
|
|
|
|
|
I believe he meant to say,
I don't think.
and An app can be properly engineered in an agile environment.
Oh, I know I've started a war now. Oh well. 
Disclaimer I'm just kidding around with the "I don't think" thing. Let's keep it light out there people.
Honestly, if you understand the heart of Agile -- if you would actually read the book by one of the originally creators of the methodology (Amazon.com: Scrum: The Art of Doing Twice the Work in Half the Time eBook: Jeff Sutherland, Jj Sutherland: Kindle Store[^] ) -- I believe you would find that Agile is really the _ONLY_ way that work gets done.
Not only in software development but in other things too.
I use the heart of Agile in everything I do.
What is the heart?
1. Make a (basic) plan of attack for your project
2. implement the steps in the plan
3. alter the parts of your plan which don't work for reality
4. iterate through 2 to 3 until you've created your product.
We who create real things know that plans are not perfect but you have to have one.
Methodologies are often over-hyped best practices that people really use and authors have turned into books.
However, the real Agile process is quite interesting. But companies (almost) always corrupt it.
|
|
|
|
|
raddevus wrote: 4. iterate through 2 to 3 until you've created your product.
And then you end up with a project that doesn't end until someone decides to stop spending money on it (or more unlikely, the customer accepts it).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Yeah, I can see what you mean.
Companies mess that up a lot really. A lot of times that's because the decision makers (ones who decide when/how the project ends) don't really understand the product or the process of actually making something.
I like the heart of Agile and agility and iterative projects, but I don't like bureaucracy or false and over-inflated processes either.
Good talk.
|
|
|
|
|
raddevus wrote: Agile is really the _ONLY_ way that work gets done
... If EVERYONE is invested in it and EVERYONE wants to pull in the same direction as their colleagues.
Many problems a company has with the management of projects can't be cured by Agile.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Many problems a company has with the management of projects can't be cured by Agile
100% agree.
I'm talking about the actual applied process of :
1. plan
2. follow plan to build pieces of project until done
3. adjust plan according to real life
4. iterate back to 2 and 3
That's all I mean about agile.
That is how real work is done.
Do companies totally mess that up? Very often, they do.
When they get it right -- or a team within the company gets it right -- then the company freaks out and starts saying, we are geniuses who should create a methodology from this great process. And that's when they screw up that good team too.
When in fact it was just real people doing what has to be really done to get something done.
|
|
|
|
|
I used to be pro agile, I am starting to have reservations though.
John is correct with his simple one line comment on Agile. I have seen more projects fail on Agile - in the end , then not - usually to a hodge podge design process (especially during maintenance enhancements) during agile, where everyone is climbing out of their ass to get the work done in the allotted sprint, usually the work is sh*t, but as you said, it gets done...but it is still stinky pile of sh*t.
No, Agile is not the answer. Perhaps a mutation of Agile (there are many) is the answer, one can only hope.
|
|
|
|
|
Slacker007 wrote: have seen more projects fail on Agile - in the end , then not
This is a danger because work often continues without oversight of how it actually impacts the project overall.
That's because Common Sense is supposed to be built-in. I know. I know. Common Sense isn't so common.
Think of the entrepreneur-developer who is creating a thing and s/he is building it.
Making it better each day, each change, each item in the work.
Hopefully that dev has some true architectural skills so when the product is complete it isn't a brittle piece of garbage.
However, I know how companies/corporations/teams work.
People along the way are like, "hey what am I supposed to do?" Then later, "Okay I did my thing." But then their contribution to the project stops there. "Hey, I did what I was supposed to do."
Agile provides a lot of nooks and crannies for things that are specifically assigned to fall into.
The project moves forward and the whole becomes less than what everyone hopes. All because no one iterated through to actually fix the stuff to make it usable.
It's a challenge.
|
|
|
|
|
your heart of Agile - looks a lot like Iterative methodolgy, which I understood to be a bit differnt in approach then Agile?
|
|
|
|
|
maze3 wrote: your heart of Agile - looks a lot like Iterative methodolgy, which I understood to be a bit differnt in approach then Agile?
Interesting.
I guess you'd have to read the book I mentioned for us to see where we are on this.
If you read it I'd be happy to discuss where I'm off the path. 
I don't know. "Agile" has been described many places in many ways, but the author is one of the original creators of the methodology. Of course I could be understanding it entirely differently from his explanation too.
|
|
|
|
|
Just a curious question here but how many years of continuous Agile experience do you have? The reason I ask is you sound very pumped up about it, and anyone who has worked with it religiously, is usually not pumped up about it. --> my experience.
Just curious...
|
|
|
|
|
I have been developing software since 1995.
I have been on projects that are not managed, mis-managed, large projects which ultimately spent $75 million on development and then failed (large mortgage bank) and small projects where I play every role in the process (BA, architect, programmer, qa, support) to get an app into production.
Again, I know that companies use methodologies as buzzwords and beat their employees with them.
I am saying that Agile is a cool iterative process that can (if properly done) expose things earlier and build community within the dev team (including QA, support, PM, etc) but alas it is often done improperly.
You must have a very strong and intelligent, gracious, experienced development manager who has real software design and architecture experience for it to go well. I have such a person in that role now. Although, in the over 23 years I've been developing software before this have not had such a person. They are rare animals and without them every methodology ends up failing.
And even in an environment which is lead by such a person, agile can fail because a team may be racing in the sprint and fixing other things isn't so fun and we all just want to run to dev the next new thing. However, I would say that with an experienced overseer they will see that happening (we are here) and understand that we have to clean things up before moving on.
But beyond all that, I love the work process of the basic agile flow. It works great for single developer projects. That's where real work is done.
Great discussion by the way.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
