Comments by "xybersurfer" (@xybersurfer) on "Thriving Technologist" channel.

i'm glad that you started posting again. this is such an interesting channel
5
i'm not sure what you mean with budget. but, i don't think a fixed budget works for agile. from my experience, it also requires an "agile" budget
4
@NicholasOrr exactly this!
3
i agree. there is basically an optimistic answer where everything goes as planned, and a more pessimistic answer where you are almost certain it's enough time. it's hard to find a balance and they try to get you to go lower. either way, i always try to communicate that it's just an estimate and name the problems i may encounter, also information or other things i expect to be ready when i get started. this is a good time to not only estimate, but to also have a critical look at the project and ask questions. what is expected from you, should be crystal clear. you basically have to cover your ass
2
that sounds crazy to me, but i frequently see such a comment. i'm guessing it's some kind of stand-up meeting. some places really need to keep those short and reduce the frequency
2
 @raptorate2872 i think you read some intentions that aren't there. it's an interesting comment
2
@gbittera that's too simplistic. there is a lot more room for interpretation, than the impression you give
2
good points. especially about time estimates. i usually just add a huge margin to my estimates, when there is a lack of information. however, long term what bothers me more is how the software industry is so used to accepting mediocre languages and other tools, that don't allow a more direct expression of ideas and make one jump through too many unnecessary hoops. this habit is a kind of tunnel vision. in my opinion, mediocre tools are the root cause uncertainty. the problems don't magically appear, out of nowhere
2
@HealthyDev a little bit technical: one of the things that immediately comes to mind is the web.config file that is part of .NET web services in and it's tight coupling with IIS, which is the server where such a web service is usually hosted. in IIS settings, the admin can set things like whether to use HTTP or HTTPS and what kind of Authentication to use (for example Basic or Anonymous Authentication, etc). the problem is that the web.config file, that's part of the web service, also requires specifying which of these will be used, or it won't work (errors). the web.config file does not have sane defaults and it's rather complicated and the documentation is rather poor. the result is that things crash when the admin changes these kinds of settings. and the developer is left trying to figure out what changed and how to mimic these settings in a poorly documented file. the struggling already happens during development, and combined with a deadline this becomes a huge issue. online you will find lot's of talk of people trying to solve web.config problems (who blames them?), not only related to IIS. but hardly anyone talks about what a mess this is that Microsoft designed. there are many more examples in other technologies and languages. i would say that this type problem, is where most of my time goes as a developer
2
@MikkoRantalainen i mostly agree. but being asked about code, could also be due to them not understanding a fundamental principal. for example: not knowing the syntax to create their own class. i've met someone that didn't know this, after decades of programming
2
thanks for sharing, that was so interesting. i had no idea that these were the kinds of problems you have faced. i've never been through such a heavy experience. mostly just technical problems caused by third parties. i personally like being creative, but i draw the line when comes to inventing new products. i can't allow myself to be exploited too much. but i agree that technical people problems, pale in comparison to people problems
2
it might come to light if management were to track time spent on issues. but good luck trying to convince them to (i haven't been able to)
1
a good time to add comments is especially when doing any kind of undocumented hacks, or making weird decisions for a good but non obvious reason. i've taken over as maintainer of a product and it dives deep into the internals of an underlying API, that we were not even supposed to touch. not having any comments explaining the choices turned out to be a disaster when some of the hacks stopped working. the fix was relatively simple in the end in a complicated piece of code, but it got delayed for months because i couldn't figure out what was going on (part of the problem being changing this generic code could fix it for one customer and break it for another). i've also noticed the same behavior in consultants, where they don't document their code. i suspect that the reason is that they think their code is not important and that it's all small one off changes. i think that's a terrible mindset
1
what's also beautiful, is when a client tries to be smart, and instead asks if i can first figure out whether something is possible, before paying to have me build it. it sounds reasonable at first. however, the result is usually that basically almost the whole thing has to be built to get that answer. and even if i record the time spent, it can still becomes a negotiation about how much they are willing to pay, and if the negotiation fails then the time spent is lost. admittedly it this doesn't happen often, but it's frustrating when it does
1
that's pretty clever
1
well said. much of our code could use an apology too haha
1
i used to do this when i was still learning to program. but now i hate overly complicated code. i take pride in the readability of my code. it usually doesn't look right to me until it is readable. people not thinking critically, about why they are adopting all these new frameworks is indeed a problem
1
also too many people on the project perhaps?
1
i don't think "all code needs comments, period" means that every line should be commented as you seem to be implying
1
@TrackedHiker i guess what "every" means is causing confusion. i don't think every method needs a comment. i think they are necessary for undocumented stuff like hacks or non-obvious things. i really don't think every file needs a comment. i write them sometimes to summarize large blocks, but i don't consider those necessary. i doubt we'll quibble though (that's not my intention)
1
@TrackedHiker one thing i've found that often helps readability is, not nesting loops in the same method
1
@HealthyDev great that you're also a .NET guy :D. you have really interesting videos in your channel (good content). yeah configuration management is a huge deal. my main gripe is with artificial barriers where no one really knows why we are doing things in a certain convoluted way, but everyone just keeps doing it (not to speak of web development. the list goes on). it's hard to be confronted with things that burn time, but could seemingly be easily improved. i feel that i may have to re-educate myself and go down a more academic path to have any hope of making a change
1
i've run into a similar problem, but with a fixed budget. i think it comes from the way some companies are used to working. from my experience, a lot of times things are not actually fixed though (which is typical in software). it helps if they can get some idea of the progress, regularly. and very often, they are wiling to drop features. ideally everything that is normally fixed should become agile too. agile development, agile dates, agile budget (customer pays for the workhours as they are spent). i think it just take companies a while to adapt, and maybe get wrong the first time, especially the budget
1
that's a tricky problem. i've seen that it's often the simple stuff brings in a lot of cash, even when half-assed (low hanging fruit). but, it's of course not good to be working on too many projects simultaneously and being rushed, especially in "experimental" projects. unless it's really obvious, i usually try to stay out of deciding the order the tasks need to be done in. i agree that Agile won't solve it
1